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Introduction to the Proceedings 


WELCOME ! ! ! 


Welcome to the proceedings of the seventh international meeting of 
users of the HP3000 computer system. This meeting was the first in 
a new era for our organization. We had formalized our structure and 
incorporated as a nonprofit organization, the HP General Systems 
Users Group (HPGSUG). This is to reflect our changing needs and 
also to more fully address the needs of the users of the HP General 
Systems Division computer products family. 


The HPGSUG is an organization of individuals with the common 
interest and goal of maximizing the benefit they can obtain from the 
use of HP General Systems Division computer’ products. These 
benefits are realized through the contributed efforts of the members 
themselves, specifically through the contributed program library and 
meetings which provide the opportunity to ‘interface and educate’. 


MEETING 


The Goal of the 1978 meeting was to provide such opportunities. 
The format of this meeting was established with the foremost 
objective being to provide a flexible framework for users to benefit 
through the collective user experience. The schedule was set to run 
five days and the sessions to be mirrored in each half of the week 
with the vendor exhibit and special sessions on Wednesday. 


PROCEEDINGS 


That brings us to this document. One goal of the meeting committee 
was to be able to provide the attendees with the printed proceedings 
at the time of registration. The result was a ‘preprint’ of this 
volume. We believe that the proceedings of the meetings provide a 
valuable source of information. It was with this in mind that we 
undertook the post conference task of assembling these materials. We 
hope this document will provide you with a guide by which to extract 
the utmost from this meeting and provide a reference to you in the 
times to come. 


The Papers / Presentation section of the proceedings is organized 
around the ‘series’ classification by major topic. There are nine 
of these major topic series which include: 


Series A Computer Applications 
5 Data Management 
Machine Utilization 
Installation Management 
Programming Languages 
Data Communications 
System Development 
System Peripherals 
Special ‘Round Table’ Sessions 


— CFCOnmonm ws 


Within each series the papers are numbered sequentially. Pagination 
follows the same organization... 


A-11.03 

* * * . 
x * *** page number within this paper 
* * 

* 


*** paper within this series or topic classification 


*** series id or major topic classification 


Please note that not all sequence numbers were used and that there 
may be gaps. For example Series H has papers HO1, HO3, HO5 and HO?7. 
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COMPUTER APPLICATIONS 


Series "A" 


COMPUTER AIDED INSTRUCTION ON THE HP3000 


Diane Christopherson 
Western Wisconsin Academic Computing Consortium 
University of Wisconsin-River Falls 
River Falls, Wisconsin 54022 


Beverly Shepherd 
Western Wisconsin Academic Computing Consortium 
University of Wisconsin-River Falls 
River Falls, Wisconsin 54022 


A-—1.1 


The original CAI package was delivered with the installation 
of our HP3000 cx machine in August of 1975. An attached note 
from the sales representative said it would be a trivial task to 
convert the package to run on our machine. After three years of 
trial, error and much frustration, CAI is now running on an HP3000 
Series II. 


A good Computer Aided Instruction package should have three 
main goals. First, it should be an instructional tool to be used 
by educators as well as a learning experience for the students 
interacting with it. Secondly, good "courseware" must be available 
to allow for optimal utilization. Lastly, and most importantly, 
it must be easy to use for a person unfamiliar with computers. 
Thus, the teacher generates text for students without concerning 
himself with programming details. We feel that this CAI package meets 
these goals. 


The CAI instructional package consists of three inter-related 
parts: IDF, IMF and Math Drill and Practice. A short description 
of each follows: 


Lesson material is prepared through the Instructional Dialogue 
-Facility (IDF) by the teacher who specifies the components of a 
course. These components include the questions to be asked with 
correct and incorrect anticipated answers, and the hints and clues 
that might be given -- together with the circumstances under which 
they are to be given. 


The Instructional Management Facility (IMF) is a set of pro- 
grams and files used to maintain Computer Assisted Instruction 
courses and make them available to the terminal user. The number 
of courses made available and the number of groups and students 
entered are limited only by the amount of storage available on a 
particular system. 


The Mathematics Drill and Practice Program provides drill 
and practice in arithmetic fundamentals to supplement classroom 
instruction. Comprehensive records of all students using the 
program are maintained, permitting automatic individualized pacing 
of each student through the curriculum. The curriculum consists 
of six consecutive years of material -- with each year's material 
arranged in 24 consecutive blocks. A student's interaction with 
the course contains pretests, post-tests and review lesscns in 
addition to the regular lesson. Depending on a student's progress, 
he/she is allowed to advance or review required material. 
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STRUCTURAL ORGANIZATION OF THE CAI PACKAGE 


Student 
Record 
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IDF 


The Instructional Dialogue Facility (IDF) enables educators to create 
and present computer assisted instruction (CAI) lessons without learning 
&@ programming language. The IDF guides them through each stage of the 
lesson creation, allowing the educators to concentrate on the instruc-— 
tional content of the lesson. 


The program records student responses and compiles statistics to assist 
in evaluating and improving course material. Using these reports, the 
educator is able to immediately assess the effectiveness of the lesson 
that he has written and, if necessary, to modify the lesson using the 
editing facilities of the IDF. The educator can analyze the lesson 
either on a student-by-student basis (in which case he sees essentially 
a reconstruction of each student's interaction with the lesson) or on 
a group basis (where he sees statistical information of student per- 
formance). 


Some other important features of IDF are: 


1. The educator may allow the student to exit from an IDF lesson to 
use a simulated calculator capability or to use or write programs in 
BASIC. The student is then returned to his lesson exit point. 


2. The educator and students are able to interact with IDF in English, 
German, French, Italian, Portugese, Spanish and Swahili. 


3. Key word searches of two different types may be specified by the 
educator for answer processing: ordinary key word and context-sensitive 
(delimited) key word searches. 


hk, String or numerical answers are allowed; ranges may be specified 
for numerical answers, and there is an automatic provision for handling 
numerically-equivalent answers. 


9. Students may request hints for problems if the educator has provided 
them. 


6. Time limits and the number of times a student can try to answer a 
question may be specified. 


{- A more sophisticated capability of IDF is in the use of as many as 
12 counters. These counters can be incremented when a student's 
response matches a correct or wrong answer. The values of these 
counters can be used to provide branching to different IDF lessons. 


A table showing how IDF guides an educator in lesson creation follows. 
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PROMPT DEFINITION 


Text Noninterrogative information 
displayed to the student before 
a question is asked. 


Question : A request for a student response. 
Correct Answer Group ) (1) A collection of one or more 
) answers the author considers 
correct. 
Wrong Answer Group ) (1) A collection of one or more 


answers which the author regards 
as incorrect but which he suspects 
that a student may try. 


or 

Correct Answer Range ) (1) A range of numbers the author 
) considers correct. If the student's 
) answer is within this range, it is 
correct. 

Wrong Answer Range ) (1) The author considers numbers in 


this range to be incorrect. 


Reply To Correct (2) ‘The message the author wishes to 
(Or Wrong) Answer have displayed to any student 
Group (Or Range) whose answer falls in a correct or 


wrong answer group or range. 

Reply to Unexpected Answer The message the author wishes to 
have displayed to any student whose 
answer was not anticipated. 

Failure Message The message the author wishes to 
have displayed to a student who 
has exhausted his permitted number 
of trials. 


Hint (3) A hint to be given to students who 
request it. 


(1) Any number of groups or ranges is allowed. 
(2) One reply is allowed for each group or range. 


(3) Any number of hints are allowed. 
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IDF has the following editing capabilities: 

1. Inserting, deleting, moving and appending sections; 

2. Inserting, deleting or changing lines within a section; 
3. Changing lesson branching; 


4. Changing options. 


The Instructional Management Facility (IMF) is a set of programs 
and files used to present Computer Assisted Instruction, record 
student progress and provide a variety of reports for the teacher 
and the course author. The number of courses made available and 
the number of groups and students entered are limited only by the 
amount of storage available on a particular system. 


Following is a list of the programs and a short description of what 
they do: 


Program Description 

ADMIN Used to enter: 
1. Each course in the IMF files; 
2. School name, code word, group names; 
3. Messages to be displayed to students; 
4, Changes in the language. 


PUPIL Used to: 


1. Enter students' names in the IMF files; 

2. Enroll students in the CAI courses; 

3. Change group assignments and session 
lengths; 

4. Drop students from courses; 

2. Obtain the Course Usage Report. 


START Asks students to sign in by typing their first 
name and identification number and the name 
of the course they wish to take. The course 
is then presented to the student. 


OUTCOM Used to: 

1. Obtain IDF Statistics Reports; 

2. View the IDF Response File; 

3. Clear the Statistics and Response Files. 
CNEWS Used to: 

1. List the News file; 


2. Clear the News file. This file contains 
comments to authors from the IDSF. 
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HPMATH 


HPMATH is a package that provides drill and practice in arithmetic fun- 
damentals to supplement classroom instruction for elementary: students. 
Lessons are drawn from a pool of problem types (blocks) that cover 
such concepts as counting, addition, subtraction, multiplication, 
division, decimals, fractions and measurement. The students are assigned 
@ starting year by their teacher; then they DE? through the course 

at their own skill level and pace. 


The curriculum consists of six consecutive years of material -- with 
each year's material arranged in 24 consecutive concept blocks. Each 
block consists of a pretest, five drill lessons, and a post-test. The 
teacher enrolls a student at the beginning of any block in any year. 
If the student scores 100 per cent in the pretest of that block, then 
he will skip to the next block. Otherwise, he proceeds with the first 
lesson in the current block. His score on the pretest determines the 
level of difficulty at which he takes the first lesson. Within the 
curriculum block, the student's score on a main lesson determines the 
level of difficulty at which he takes the next main lesson. His score 
is determined by the number of correct answers he gives. The student's 
post-test score is recorded and used to determine whether he should 
review a curriculum block. 


The system generates reports which keep the teacher informed of each 
student's progress. The following reports are available to the teacher: 


1. Daily Report 


This shows the following exceptional conditions: 


i. Performance of a student below 60 per cent at level 1; 
ii. A student skipping consecutive blocks; 
iii. A student reaching a new concept block; 
iv. Absences -- a student not taking the course. 


2. Student Report 


This contains post-test scores on blocks completed by the student, plus 
the number of times the block was reviewed. 


3. Progress Report 


This lists each student in the group, his exact position in the 
curriculum, and how many blocks he has completed to date, 


4. Course History Report 


This presents a statistical summary for the year (primarily of interest 
to school curriculum specialists) showing average and standard deviation 
of pre- and post-test scores. 


5. Lesson Report 


This provides the teacher with a sample lesson for any year, block and 
level. 


6. Usage Report 


This lists the students in alphabetical order with their identification 
numbers and the number of hours they spent using the math course. 


7. Roster Report 


This provides a permanent reference listing of students their ident~ 
ification numbers and their time limits. 
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IDF: A SAMPLE RUN 


An example of a lesson created using the Instructional Dialogue 
Facility is shown below. The computer prompts the author for 

all of the structural elements in the natural order. For clarity, 
entries typed by the author are underlined. 


SECTION # 1 

OPTIONS? KEYWORD cr 
OPTIONS? cr 

TEXT: 


? RECALL FROM OUR PREVIOUS LESSON THAT GEORGE Il er 
? RULED GREAT BRITAIN FROM 1727 TO 1760, AND cr 


anc cm a nn SS a DEE CE OSC Ome 


? THAT DURING HIS REIGN BRITAIN HAD A SERIES cr 


2? OF WHIG PRIME MINISTERS. cr 
? cr 


QUESTION: 


2? WHO WAS THE FIRST PRIME MINISTER TO SERVE cr 
? UNDER GEORGE II? er 
? cr 


CORRECT ANSWER GROUP: 


2? WALPOLE cr 
? cr 


REPLY FOR THIS GROUP: 


? THAT’S CORRECT: ROBERT WALPOLE WAS PRIME cr 

2? MINISTER UNDER GEORGE I FROM 1714 TO 1727; WHEN cr 

2? GEORGE II ASCENDED TO THE THRONE IN 1727, WALPOLE er 
2? BECAME THE FIRST PRIME MINISTER UNDER HIS REIGN. er 

? cr 








WRONG ANSWER GROUP # 1 


2? COMPTON cr 
? cr 


REPLY FOR THIS GROUP: 
2? NO—COMPTON WAS THE SECOND PRIME MINISTER TO cr 


? SERVE UNDER GEORGE II; PLEASE TRY AGAIN. cr 
? cr 
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WRONG ANSWER GROUP # 2 


? PELHAM cr 

? HOLLES cr 

2? CAVENDISH cr 
? cr 


REPLY FOR THIS GROUP: 


? NO—HE DID IN FACT SERVE AS PRIME MINISTER UNDER cr 


? GEORGE II, BUT WELL AFTER THE MAN I’M THINKING cr 
2? OF. PLEASE TRY AGAIN. er 
? cr 

WRONG ANSWER GROUP # 3 


? WALP cr 
? cr 


REPLY FOR THIS GROUP: 


? ITHINK YOU HAVE THE RIGHT ANSWER, BUT YOUR er 


? SPELLING IS WRONG; PLEASE TRY AGAIN. cr 
? cr 


WRONG ANSWER GROUP # 4 
? cr 

REPLY TO UNEXPECTED ANSWER: 
? NOW STOP PLAYING AROUND: NO ONE BY THAT NAME cer 
7? EVER SERVED AS PRIME MINISTER IN GEORGE II’S er 


? TIME. PLEASE TRY AGAIN. er 
? cr 





FAILURE MESSAGE: 


? WELL, IT DOESN’T LOOK LIKE YOU’RE GOING TO GET er 
? THE RIGHT ANSWER ON THIS ONE, SO ’LL TELL YOU. er 
? THE MAN I’M THINKING OF WAS ROBERT WALPOLE: HE er 
? SERVED AS PRIME MINISTER UNDER GEORGE I FROM cr 
? 1714 TO 1727, AND WHEN GEORGE II ASCENDED TO THE er 
? THRONE IN 1727, WALPOLE BECAME THE FIRST PRIME cr 
? MINISTER UNDER HIS REIGN. er 
cr 


HINT # 1 





? THE MAN I’M THINKING OF ALSO SERVED AS PRIME er 
? MINISTER UNDER GEORGE I. NOW TRY AGAIN. cr 
aaa 
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IMF: A SAMPLE RUN 


An example of using the Instructional Management Facility appears 
below. It shows how to enter a school, group, course and student 
names into the IMF files. 


ATIMIN 
COTE PHB MyM py 
COMMAND? 7 SHELE 
VTYPE CODE» SCHOOL» GROUP» COURSE»: MESSAGE» RESET» LANGUAGE: OR FUFTIL, 
COMMAND? SCHOO, , 
SCHOOL NAME?PC OAT HIGH 
SCHOOL NAME IS NOW CAI HIGH, 





COMMAND P GROUP 
GROUP COMMAND? 7 / HEL 
TYFE ENTER: CHANGE» REMOVE» OR LIST. 
GRQUPF COMMANT?PENTER 
NEW GROUP Narre PoROUE 
GROUFI IS NOW ENTERED AS A GROUF, 





NEW GROQOUF NAME PORQUE? 
GROUPS JIS NOW ENTERED AS A GROUF, 


NEW GROUP NAME? 
GROUP COMMANT? 
COMMAND? COURSE 
COURSE COMMAND? Y “HELE 
TYPE ENTER: CHANGE: REMOQVEs OR LIST, 
COURSE COMMANITENTESR 
CQURSE NAMEPHIESTORY 
CODE WORTH | 
NOES IT HAVE A DEMO MODETYES 
SFECTAL COURSE TYFE?TINF 
HISTORY IS NOW ENTERED 4S A COURSE, 


COURSE NAME?TMATH. FUR. CAT 

COVE WORD TMATH 

NOES IT HAVE A DEMO MODE?YES 

SFECTAL COURSE TYFPETMATH 

MATH.FUB.CAI IS NOW ENTERED AS A COURSE 


e 


COURSE NAME? 
COURSE COMMAND? 
COMMANIPPUF IL 
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PUPIL 


COMMANDVE//HELE 


TYPE ENTER» CHANGE»: REMOVE» RESET» ADMIN» ENROLL» ALTERs 


COMMANTTENTES 
FIRST NAME POTANE 
LAST NAME ?CHRISTOPHERSON 
ENTERED WITH IT) NUMBER 1000, 


COURSE NAME?MATH.FURB,CAT 
GROUP NAMETGROUF I 
STARTING YEAR TA. 
ENROLLMENT CONFLETED. 


FIRST NAME VREVERLY 
LAST NAME ?TSHERHE RD 
ENTERED WITH ID NUMBER 1001, 


COURSE NAME ?THISTORY 
GROUP NAME?PGROLP 
ENROLLMENT COMPLETED, 





FIRST NAME? 
COMMAND PL TST 
LIST BY If» NAME> OR COURSE?TIO 
PAGINATE?NO 
IN) RANGE?TITOOO2 1001 


coed Game seme cere cme 


CAI HIGH 6 OCT, 1978 8:50 AM 
It} LISTING PAGI 1 


FREFERRED TYPING ENROLLED 
COURSE 


ri NAME LANGUAGE MULT. 
1000 CHRISTOPHERSON: IRIANE ENG 1 
1001 SHEPHERD: BEVERLY ENG 1 


02 ERD Gree ostt Core 


Tt RANGE? 
LIST BY Itty NAME» OR COURSE? 
COMMAND? //STOF 
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QROF:s OR LIST. 


FORT NQ. 13 


USAGE 
(HRS) 


MATH.FUBR,CAI 20 
HISTORY 


79 


HPMATH: A- SAMPLE RUN 


2S TART 
li-rrar case onlyPYES 


Se EE Eee Ch Pie eS ED HS Sb ote 


Flease tyre your Ill number end first namet 1000 DLANE 


Is your last mame CHRISTOPHERSON?TYES 


6 October 1978 ~—69 301 Fort 13 


HELLO DIANE, WE HOPE YOU ENJOY ToDAY’S PROBLEMS, — 
M 46061 


KKKKKKAKKK HERE WE GO Fh bl! HRaKKEKKKK 
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18 
+ 16 


bbe C866 5605 GOED 


28 


36 


34 


39 
~ 20 


oa¢ mom pred Otte 


8 


WRONG » 


39 
~~ 20 


19 


28 
= to 


13 


ENTER 


& t+ il 


TRY AGAIN 
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Sor G & 2+ 3 


LESSON OVER, YOU ANSWERED 24 OUT QF 27 QUESTIONS CORRECTLY. 
GOODBYE DIANE. 


eebe 660) FerR CER Cewe EEUD PEEP Gane Sens ane 


Flease tyre your ID number and first mame: //STOF 
PEXIT 
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COMPUTER ASSISTED RESIDENTIAL ENERGY AUDIT 


DR. NEAL H. PROCHNOW 

PHYSICS DEPARTMENT 

UNIVERSITY OF WISCONSIN-RIVER FALLS 
RIVER FALLS, WI 54022 


MARLYS NELSON 

WESTERN WISCONSIN ACADEMIC COMPUTING CONSORTIUM 
UNIVERSITY OF WISCONSIN-RIVER FALLS 

RIVER FALLS, WI - 54022 


The 1973 oil embargo focused this Nation's attention on its energy 
resources and precipitated increased costs for energy. The increased 
costs for energy resulted in monthly fuel bills for home owners which 
were twice that of previous years. A study in 1974 by the Department 
of Health Education and Welfare in cooperation with the Federal Energy 
Administration indicated that those hardest hit by the rising prices 
of home heating fuel were the poor who lived in single-family homes 

in the colder parts of the country and heated their homes with fuel 
oil. As a result the Community Services Administration (CSA) initiated 
in 1974 an energy conservation program via weatherization of homes. 
This program was delivered to low-income home owners by local communi- 
ty Action Agencies (CAA). It became apparent as a function of time 
that this program would be more effective if technical assistance 
could be provided to the weatherization crews, education to the 

home owners and management capabilities to the administrators of 

the program. As a result CSA provided funds for the development of 

a computer assisted energy audit management program. The program 
described in this paper is a spin-off of the program developed for 
CSA. The authors wish to thank Miriam Charnow at CSA National and 
Carl Saueressig at West CAP for their assistance and the personnel 

at West CAP for their cooperation in the development of the program. 
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The energy conservation awareness created by the 1973 oi] embargo has 
somewhat dissipated. There are no long lines at service stations 
and there appears to be ample fuel for heating homes. The severe 
winter of 1976-77 is long forgotten and to some extent the glamour 
of solar energy and other alternate energy sources has attracted 
the general publics' interest instead of something as mundane as 
Insulating a home. However, energy conservation must still remain 
as one of the most important objectives of any energy program for 
this country. The problem is to keep the concept of energy conser- 
vation in focus. Energy conservation requires a conscious effort 
and it seems as though the majority of adults react to it only via 
a catastrophe or a series of catastrophies; OPEC embargo, severe 
1976-77 winter, etc. This is a difficult and traumatic way to 
maintain energy conservation awareness. Perhaps a more rationale 
way is to build the awareness in from the very beginning. 


The United States has in place an elaborate education system and 
this system can be used to create an energy ethic. However, this 
mechanism still presents some problems. The energy problem is 

a social-cultural problem as well as a technical problem. Most 
teachers do not have the necessary information base to 

efféctively build an energy ethic into their students. An even 

more important consideration is that most teachers are so overburdened 
with the existing curriculum that there may be little or no room for 
energy to be added. This is further compounded by the back to the 
basic demands currently being placed upon school curriculums. The 
time element also becomes a factor. It is perhaps most rationale 

to begin at the beginning, kindergarten, and create a process 

such that the ultimate result at grade 12 would be an energy con- 
scious responsive individual. However, the developmental time and 
implementation time is too long for immediate results and may be 

too long to be sustained. Subsequently, there may be more cycles of 
energy catastrophe, reaction, etc. With all these factors in mind, 
it seemed apparent that if something was going to be done in the 
energy conservation area via students, it would have to compensate 
for all the factors indicated above. The interactive audit is a mecha- 
nism to do just that. 


The audit is designed for use by students, grades 7-12. However, it 
can be used with college students and adults. Students using the 
audit are required to perform a series of activities. These activi- 
ties can be coordinated very easily with the existing curriculum or 
can be done totally independent of the curriculum. The first acti- 
vity requires the student to perform a structural assessment of his 
home with respect to energy efficiency. This assessment requires 
either a booklet or a data sheet as an explanatory device. West CAP 
is using the audit as a part of a youth energy conservation program 
and has developed a booklet and summary data sheet. Appendix A is a 
copy of the data sheet used by West CAP. The audit can be described 
most efficiently via a discussion of the questions involved in the 
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assessment. Note that the fact that the student is required to perform 
an assessment of his home builds in an opportunity for parent-student- 
teacher interaction with respect to energy conservation. 


The program can be used in a no instruction or instruction mode for 
data entry. In the instruction mode the entire question is printed 

by the computer, while in the no instruction mode only the line number 
and a question mark is printed. For all inputs the number entered is 
checked to see if it corresponds to reality where possible. Items 

two and three of Appendix A show sample data entries in each mode. 


Question |1.: Date 

As has been indicated some mechanism is needed to create awareness 
with respect to energy conservation. The mechanism in this case is 
the interactive capability of the audit. However, even the use of 

a computer is insufficient to maintain interest if the time to get 
results is too long. The time to enter the data and get a complete 
output ranges from 10 minutes for very few system users to 20 plus 
minutes if the system is saturated and the no instruction mode is 
used. Of this time,3 to 5 minutes are required to enter the data. 

In order to increase the flexibility the management portion of the 
program contains a file to temporarily store the answers needed to 
print the output. The status of this file is indicated when the 

user elects to use the audit program. If the file is not full (50 
jobs currently allowed), the user can elect to enter the data and 
obtain his output up to 3 days later. If the file is full the user 
must obtain his output immediately after the data is entered. If 
this is impossible for him he need not initiate the program. The 
file is checked daily as a part of system back up and any data stored 
in excess of the three day limit is purged. The data js automatically 
purged after an output is obtained. The date js required to incorporate 
this feature. 


Question 2.: YOU 1.D. Number 

The program is designed to store the energy conservation results of 
all the audits performed. In order to identify the audits performed 
by users on an individual basis a unique number can be assigned to 
identify their data. If this is not essential or desired the YOU 
!.D. number can be any number the user elects to enter. 


Question 3.: House Number 

The house number is computer assigned. This number is used to keep 
track of the total audits as well as allow the user to obtain his 
data at a later date. 


Question 4.: Number of Home Occupants 


The number of occupants is used to obtain an estimate of the hot 
water requirements. 


A-92.3 


Question 5.: Age of Home 
This data is useful to State and Federal Agencies. 


Question 6: Roof Condition 
The condition of the roof is critical with respect to adding insulation 
to the attic. 


Question 7.: Heating System Condition 

The condition of the heating system is critical with respect to energy 
efficiency. Most if not all students do not have the skills to assess 
the condition of the heating system. However, the students can make 
the homeowner (their parents) aware of the fact that it should be 
checked. If the heating system has been serviced recently (2 to 3 
years), it is considered to be in good condition; if not repairs may 
be needed. If it doesn't work it needs to be replaced. 


Question 8.: Home Temperature-Day and Night 

The average temperature of the home is needed in order to obtain 

the heatloss. The average temperature is computed assuming a 
weighted average of the day and night temperatures; 1/3 for night 

and 2/3 for day. The design temperature of home is assumed to be 
70°F and the heatloss is adjusted at 3% per degree. The temperatures 
input can be determined by asking the homeowner or by measurement. 


Question 9.: Degree Day Zone 

The heatloss is determined on an annual basis using degree days. In 
most states degree day data is available as a function of geographi- 
cal area. For example, the State of Wisconsin is divided into 1] 
degree day zones. Usually the degree day data is available for a 
65°F base. Recent data from the National Bureau of Standards (NBS) 
indicates that a 55°F base may be more appropriate. This is consis- 
tent with UW River Falls fuel bill analysis and hence the 65 base 
data has been adjusted to 55 base data. All degree day data used 
should be adjusted to the 55 base. In addition a 242 day, September 
15 to May 15, heating season is assumed. 


Question 10.: Type of Fuel and Fuel Cost 

Nine types of fuel are allowed; gallons of #1 oil, gallons of #2 
oil, kilowatt-hours of electricity, cubic feet of gas, therms of gas, 
gallons of LP, tons of coal, gallons of kerosene, and full cords of 
wood. The energy content of the fuels and efficiencies assumed are 
documented in the program and are consistent with latest NBS data. 
The fuel cost can be input or if it is unknown an average value is 
assigned by the computer. The average values used for the cost of 
fuel as well as all other standards must be determined regionally 
and periodically updated by systems staff. The rationale on the 
design ts to place responsibility for parameters on a systems 
individual rather than on a sub routine built for all regions for 
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all time. That is, decisions on prices, standards, etc. are best 
made by an informed individual rather than by a complex subroutine 
designed to guess the future. 


Questions 1]. to 14.: House Structure 

The program has been field tested for 1,2 and 3 story homes. The 
data entered for these questions is used in the heatloss calculations 
as well as to provide checks on reality. For example, the wall area 
is calculated from the data of questions 12. to 14. and is used to 
check the data entered in questions 27. and 28. to ensure a reason- 
able value for the wall area. In addition, the first floor area is 
used to check the ceiling area and floor area for the attic and 
basement heatloss calculations. 


Questions 15. to 17. and 20. and 21.: Basement Heatloss 

An explanation of the methodology of how the basement heatloss is 
calculated is beyond the scope of this paper. What is needed js 
the type of basement and associated dimensions such as the floor 
area (from question 12.), perimeter, amount exposed above ground 
and composition of the floor with respect to R-value. The R-value 
of a material is a necessary concept and either the user must have 
a working knowledge of it or obtain it by reading accompanying ma- 
terial. It is a simple concept and poses no problem if a small 
amount of time is devoted to it. The program is most accurate for 
homes with basements followed by homes with crawl spaces and then 
walkout basement homes. The answers obtained for trailer homes 
skirted and unskirted are very crude. This is because there is very 
little data available to check the methodology for trailers. 


Questions 18. and 26.: Itnfiltration-Foundation and Walls. 
Infiltration is an important consideration in heatloss. What is 
required is to assess the extent of air leakage into or out of the 
home. This is usually done by rating the structural components 

1,2 or 3; that is good, mediocre, or bad. The resulting heatloss 
is then computed by using infiltration functions for the various 
components. In this program infiltration functions have been 
derived for the foundation, crack length, the wall crack length and 
the window and door crack lengths. The wall crack length refers 

to the crack length associated with the window and door frames 
where they join the wall siding. The rationale is that the crack 
lengths to be considered must correspond to those places that leak 
and are caulked, weatherstripped or sealed in some fashion. A 
major source of infiltration is associated with opening and closing 
windows and doors and/or leaving them open. There is no way to 
account for this in this model and this loss is not related to 

the structure but to the occupants behavior. 


Questions 22. and 23.: Ceiling Area and R-Value 


The program allows for two types of ceiling areas. The rationale 
is that a reasonably large number of homes have an addition which 
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has a different ceiling R-Value. In all cases the R-Values entered 
are for structural components only and R-Values for air films, etc. 
are assigned internally in the program. 


Questions 19., 24. and 25.: Windows and Doors 

The windows and doors of a home can represent a large heatloss. 

What is required is the direction, area, an infiltration judgement 

and whether or not there is a storm. The direction is not critical 
because it is used only to identify the window or door. The degree 

day concept contains the heat gain or loss due to sunshine. The 

window and door areas are computed from length and width measurements. 
The criteria for judging the infiltration are included in the data 
summary sheet. The window or door either has a good tight fitting 

storm or it is considered not to have a storm. An allowance is made 

for windows of the same size, direction and condition. The infiltration 
functions have been designed for double hung windows and are approximate 
for other types of windows. Question 25. requires the user to indicate 
whether or not the windows are double hung. This information is used 

to check the validity of the infiltration functions. 


Questions 27. and 28.: Wall Area and R-Value 

As in the ceiling case, two wall areas are allowed to account for the 
Fact that a large number of homes may have a part of the home with 
insulated walls and a part of the home with uninsulated walls. The 
area to be entered is the area associated with the living space. 

The program checks this entered area against the area computed from 
the earlier structural data. The R-values entered are for the wal] 
materials only. 


As can be seen from the brief description of the questions, the 
assessment activity can be used to enhance the existing curriculums 
in both the mathematics and science areas. In addition, energy 
concepts such as R-values can be added with a minimum of time. 


The second activity of the audit consists of entering the data either 
via the instruction or no instruction mode. This can be an enhancing 
activity for a class which does not have usual access to a terminal 
or it can be just another program execution. Item four of Appendix 
A contains an example of the output. The output is reasonably 
self-explanatory and need not be discussed with the exception of 

the opening paragraph. While the computer community has the utmost 
confidence in output, the general public does not necessarily share 
this confidence, particularly if energy is involved. Therefore, 

a check on reality is built in via the total fuel bill. That is, the 
homeowners faith in the results increases as the computer guesses 
more accurately his total heating bill. This mechanism provides a 
reality check on the output. 
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The third activity can consist of the interaction of the student and 
the homeowner via the audit output. This interaction can be kept 
minimal or expanded depending upon the use of the audit and the 

time and energy of the participants. 


The audit has the potential to be very useful depending upon its 
implementation. The program including the management aspects is 
reasonably large. It consists of 15 segments written in HP-3000 
Basic and | segment written in HP-3000 SPL. All segments are less 
than 8K words. The temporary output file with a 50 job limit re- 
quires 4500 sectors. The management file on school use has a 100 
sector limit and the information from the audit which is stored 
permanently occupies 1/2 a sector per job. The correct time to run 
the program ranges from 10 to 20 minutes plus depending upon the 
volume of users. The CPU time is about 5 seconds. 


The program currently stores permanently the following information: 


YOU |.D. Number 

Age of the Home 

Type of Fuel 

Attic Insulation Standard 

Total Floor Area and Volume of Home 

Average Temperature of the Home 

Total Ceiling Area and Weighted R-Value 

Total Wall Area and Weighted R-Value 

Infiltration Judgement for the Walls and Foundation 
Average Infiltration Judgement for the Doors and Windows 
Window and Door Area | 

Heatloss in Fuel Units and Dollars 

Potential Heat Savings in Fuel Units and Dollars 

Percent of the Heatloss Due to Infiltration and Conduction 


While the implementation of the program would require very little 
effort from one HP-3000 to another, some training with respect to the 
energy and heatloss aspects would greatly enhance the effectiveness 
of the audit. Because the audit can generate data related to resi- 
dential energy use, there is a possibility that Federal funds can be 
obtained to provide some training. If you are interested in imple- 
menting the audit please contact one of the authors of this paper. 
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APPENDIX A 


A sample data summary sheet is included to illustrate the technique 
used to increase the efficiency of data entry. This sample data 
sheet consists of one folded piece of paper but is displayed here 
as four separate sheets. 


Sample data entries are enclosed in both the no instruction and 
instruction modes. For some entries errors have been made to 
illustrate the kinds of data checks built into the program. 


A copy of the output is enclosed. Note the narrative form of 
the output. This enhances the ability of the homeowner to read 
and understand the results. The sample data entry in the 
instruction mode and the output required 22 minutes of connect 
time and 7 seconds of CPU time. There were 23 users and the 
data entry and output were obtained via DSLINE communication. 
In the no instruction mode with no DSLINE the typical data 

in output out connect time is less than 15 minutes with a 

CPU time of 4 to 5 seconds. 
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Housing & Energy VISIT 

West CAP #1 19, 

525 Second Street DATA ON BACK 
Glenwood City, WI 54731 #2 











ES Se 20, 
NAME OF HOMEOWNER. —— s——“‘CCCS#CT @Lephone # 
1.- DATE: MONTH, DAY, YEAR (E.G. 1,10,78) 1. Sains earn ht Fee 
2. Y.0O.U. ID NUMBER 2. 
(computer assigned, if you wish 
3. Assigned House Number to recall program record here) ne 7 pense, foe 
4. Number of Individuals Occupying Hom: | iy : 
5. AGE OF HOME (YEARS) 5% 
24. ; 
6. CONDITION OF ROOF? 6. sé COON’ BACK 
l=Tight Roof - no leaks, good condition 
2=Needs Mtnor Repair - missing shingles, cracks, 
possible leaks es 
3=Needs Replacing - bad condition, major leaks DATA ON BACK 
7. CONDITION OF HEATING SYSTEM? Wen = 26. 
l=serviced within 1 year 
2=serviced 1-5 years - owner can recollect it's 
having worked better 27, _ ts 
3ecan't recollect last date of service 5a 
a _——— 9 ea ee ss 
8. AVERAGE HOME TEMPERATURE (FARENHEIT) 8. ly 
Day Time » Night Time 
9. DEGREE DAY ZONE (SEE PAGE 2) 9. 
10. FUEL NUMBER AND COST (SEE PAGE 2) 10. > 
ll. NUMBER OF STORIES IN HOME 3 
11 TO CONDUCTION 
12. 1st FLOOR AREA (SQ.FT.), AVG. WALL HT. (FT.) 12. ; 
13. 2nd FLOOR AREA (SQ.FT.), AVG. WALL HT. (FT.) 13. ; _- 
14, 3rd FLOOR AREA (SQ.FT.), AVG. WALL HT. (FT.) 14. ; ee er 
15. FLOOR EXPOSURE FACTOR 15. 
l=Basement 
2=Crawl Space 
3=Walkout 
4=Skirted Trailer/Building on posts 
2=Unskirted Trailer/Building on posts 
Are the basement walls insulated? 1=Yes 2=No — 
Walkout wall area (sq.ft.) and R-value 4 
16. FOUNDATION PERIMETER (FT) 16. 
17. AMOUNT FOUNDATION EXPOSED ABOVE GROUND (inches)? 17. 
18. FOUNDATION CONDITION NUMBER 18. 


l=no cracks or settling, very clean 
2=minor cracks, loose morter 
3=major cracks and settling 
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SS ye hE 


FUEL FUEL COST 

(circle one or more, enter major fuel on item 10). 
l= #1 Fuel Oil (cents per gallon) 
2= #2 Fuel Oil (cents per gallon) 
3= Electricity (cents per kwhr) 
4 Natural Gas by Cu. Ft. (cents per cubic foot) 
5= Natural Gas by Therm (cents per therm) 
6= Bottled Gas (LP Propane) (cents per gallon) 
7= Coal, Coke (dollars per ton) 
8= Kerosene (cents per gallon) 
9= Wood (dollars per full 


cord, 4x4x8 Ft.) 
If fuel cost is unknown, computer will assign an average cost. 


COUNTY DEGREE DAY ZONES Enter on item 9 


Chippewa, Barron, Polk = 4 
St. Croix, Dunn, Pierce, Pepin = 7 





CRITERIA FOR DETERMINING THE CONDITION OF DOORS, WIDOWS 
AND WALLS 


Condition 1= DOORS, WINDOWS—- good fit, no draft is felt, 
caulk and weatherstripping are in good shape. 
WALLS- finish in good shape. 


Condition 2= DOORS- loose or missing weatherstripping. 
WINDOWS- loose fit, no weatherstripping, caulk 
and glazing cracked and missing in sections, 
storm open or cracked. 
WALLS- caulking between wall and frames is 
cracked, shrunk or nonexistant. 
WALL EDGE AT FOUNDATION- shows minor deterioration. 


Condition 3= DOORS- large gaps between door and jamb. 
Door cracked, sagging on hinges. 
WINDOWS- very loose, window glass broken or 
missing. Frame shows rotted areas. 
WALLS- rotted areas, large gaps between wall 
and frames. 
WALL EDGE AT FOUNDATION- show deterioration, missing 
siding and holes. Foundation has many cracks or 
holes. 
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19, BASEMENT WINDOWS: HOW MANY LINES FILLED IN? 19. 
ENTER BASEMENT WINDOW DATA FROM REVERSE SIDE DATA ON BACK 


20. CARPETED FIRST FLOOR AREA (SQ.FT) 20, 
INSULATED 1:Yes 2=No 
R-Value if Yes 


21. First Floor Area NOT CARPETED (SQ.FT.) 21. 
Insulated 1=Yes 2=No 
R-Value if Yes 


iM 





22. UNINSULATED CEILING AREA (SQ.FT.) AND R-VALUE 22. ; 

23. INSULATED CEILING AREA (SQ.FT.) AND R-VALUE 23. : 
MATERIAL DEPTH 

24. WINDOWS: HOW MANY -LINES FILLED IN? 24. ’ 
DOUBLE HUNG 1=Yes 2=No DATA ON BACK 
ENTER WINDOW DATA FROM THE REVERSE SIDE 

25. DOORS: HOW MANY LINES FILLED IN? 25. 
ENTER DOOR DATA FROM THE REVERSE SIDE DATA ON BACK 

26. WALL CONDITION NUMBER (1, 2 or 3) 26. 

27. TOTAL OUTSIDE WALL AREA INSULATED (SQ.FT.) AND R-VALUE 
MATERIAL 27. ’ 

28. TOTAL OUTSIDE WALL AREA UNINSULATED (SQ.FT.) AND R-VALUE 28. : 


COMPUTER OUTPUT 





HEAT LOSS FUEL COST 

___% DUE TO INFILTRATION % DUE TO CONDUCTION 
POTENTIAL SAVINGS 

HEAT LOSS FUEL COST 

SQ.FT. VOLUME 


COMPUTATION SPACE 
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BASEMENT WINDOW DATA 


See second page to determine condition number for windows and doors. 












































Direction Condition Good Storm Number of 
Inches 1,2 or 3 l=Yes, 2=No Windows 
a eed ee nS mane nS) 
ir Teas Cen ene AReCiN 
Leia eoe leet ee hater Ole he a 
ee ee ac eee ee ee 
[eis es ee ee 
WINDOW DATA 
Height Condition Good Storm Number o 
»S,E,W Inches 1=Yes =No Windows 
aa ee ara 
ena | fe eee 
a Te este eee 
a rae Re 
eee es ee eas | 
ee Pee ee 
a ee a 
Ts Is ote eo a 
a ere leeae on ate 
ea Ia Eee ee oe 
Eee ee ee ae eae 
eee eee ene aare 
ee a, ae 
Rae Raa aaa 
aes eae ae 
DOOR DATA 
Direction Width Height Condition 
N,S,E,W Inches Inches 1,2 or 3 . 
es ie Pee es 


Sanat SARI! SRE! Sas 
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UW - River Falls HEATLOSS Frosram { TUEy OCT 3»y°1978y 11°16 AM 


¢ 


Enter two (2) cisit code for desired ortion + 
O1 Home enersy audit 02 Outrut stored audit information 
99 Stor 

401 


Storade srace om file is available at this timer vou may he able to 


store your audit information and receive outrut at a later time. 


NEED INSTRUCTIONS (1=YES OR 2=NQ) ? 2 


1073778 
2. ? 2 
3. 100013 


fob 
~) 


ch 


oO 
cd 
ee ee 
co 
a 
a 
Ch 


HPbarRR HH 


10. ? 
P?Ry1LOO0 
RAD INPUT~-RETYFE FROM ITEM 1 
PP12100 


x K ENTRY NOT REALISTIC & * FUEL COST FOR TYPE OF FUEL INDICATED MUST 
BE BETWEEN 30 AND 65 CENTS INCLUSIVE, FLEASE REENTER DATA. 


[LO YOU KNOW THE AFPPROFRIATE FUEL COST (1=YES OR 2=NO) ? 2 

11. ?P 1 
12. 7 34378 
1S. ? 1 

INSULATED ? 2 
14. ? 94 
17. ? 6 
18. 7? 1 
19. 7? 0 
20. ? 180 

INSULATEN (1=YES OR 2=NQ) 7? 2 
21. ? 363 

INSULATED (1YES OR 2=NQ) 7? 2 
22 6 ? 079 
23. ?P S45724 
245 ? Ovl 


xX KX ENTRY NOT REALISTIC * *A HOME MUST HAVE AT LEAST ONE (1) WINDOW. 
PLEASE REENTER DATA. 
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24. WINKOWS $ NUMBER OF LINES FILLED IN (1-45) AND TOUBLE HUNG (1=YES 
OR 2=NO) ? Syl 
P We S0r50xL e291 


P SrSOr50x12193 
P WeSO0xr50x12291 
2o0 ? i 
P Ev Slrx84er1 91 
264 ? 3 
w/e ? 00 
28. PP 75293 


DO YOU WISH TO STORE INFORMATION UNTIL LATER (1=YES 2=NO) ? 1 


Enter two (2) digit code for cesired option : 


O1 Home energy sudit O02 Outrut stored audit information 
99 Stor 
“99 


HEATLOSS RUN TERMINATED. 


FRYE - 

CPU=3. CONNECT=10. TUE» OCT 3» 1978» 11224 AM 

* XX K GOOI-BYE FROM WACC I Xk &k &k A SERVICE OF UW-RIVER FALLS x x x 
END OF SESSION 

#3 


‘BYE 
CPU=3. CONNECT=11. TUE» OCT 3, 1978» 11325 AM 


* X K GOOD-BYE FROM WACC II * k Xk A SERVICE OF UW-RIVER FALLS x x x 
END OF SESSION 
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UW - River Falls HEATLOSS Frogram : TUEy OCT 3: 1978 10347 AM 
Enter two (2) disit code for desired ortion +% 

O1 Home enersty audit 02? Outrut stored audit information 
99 Stor 

401 


Storade srace on file is available at this timey you may be able to 
store vour audit information and receive outrut at a later time, 


NEEM INSTRUCTIONS (1=YES OR 2=NO) 7? 1 


THIS FROGRAM IS DESIGNED TO SAVE COMPUTER TIME. THEREFORE ANSWER 
THE QUESTIONS AS ACCURATELY AS POSSIBLE. PLEASE REAL THE BOOKLET CARE- 
FULLY ANI USE THE DATA SUMMARY SHEET. IF YOU tO NOT KNOW AN ANSWER, IO 
NOT GUESS THE ANSWER. IF YOU ARE UNSURE ANI! HAVE A CHANCE TO ANSWER NO» 
THE COMFUTER WILL ASSIGN A REASONABLE VALUE WHERE FOSSIBLE. YOU WILL BE 
GIVEN ONLY 4 CHANCES TO ENTER THE CORRECT INFORMATION (WITH HINTS) HE- 
FORE BEING TERMINATED. 


1. DATE (MONTHy [tAYs YEAR) ? 1093378 

2. Y.Q.U. I.0). NUMBER ? 2 

3. HOUSE NUMBER $ 100012 

4. NUMBER OF INDIVInNUALS OCCUPYING HOME 7? 1 

S., AGE OF HOME (YEARS) ? 25 

6. CONDITION OF ROOF $ 1 = TIGHT ROOF 2 = MINOR REPAIRS NEEDED 
3 = NEW ROOF NEERED fF ft 

7. CONDITION OF HEATING SYSTEM ¢ 1 = GOOD CONDITION 2 = NEEDS REFAIR 
3 = NEEDS REPLACEMENT 7? 1 

8. AVERAGE HOME TEMPERATURE (FAHRENHEIT) $ DAYTIME ANID NIGHTTIME. 
SEFARATE EACH ENTRY WITH A COMMA. FOR EXAMPLE: 68746 ?F 70770 

9. ENTER THE ZONE NUMBER WHERE HOME IS LOCATED ? 7 

10. ENTER FUEL NUMBER ? & 
DO YOU KNOW THE FUEL COST (1=YES OR 2=NQ) 7? 1 
ENTER FUEL COST ? 23 

li. ENTER NUMBER OF STORTES ? 1 

92, ENTER FIRST FLOOR AREA (SQ.FT.) ANT AVERAGE WALL HEIGHT 
(FT.) ? 3438 

15. ENTER FLOOR EXPOSURE FACTOR ? 1 
ARE THE BASEMENT WALLS INSULATED (1=YES OR 2=NQ) 7? 2 

16. ENTER FOUNDATION FERIMETER IN FEET ? 94 

17. ENTER AMOUNT FOUNDATION IS EXFOSF0 IN INCHES ? 6 

18. ENTER FOUNDATION CONDITION NUMBER ? 2 

19. HOW MANY LINES FILLED IN FOR BASEMENT WINDOWS 7? 2 
ENTER RASEMENT WINDOW DATA AS FOLLOWS : ENTER INIRECTION (Ny Ss E OR 
Ws WIDTH CINCHES)» HEIGHT (INCHES)» CONDITION (1s 2 OR 3)r GOO! 
STORMS (1=YES OR 2=NQ)» NUMBER OF WINDOWS OF SAME DIRECTIONs CONDITION, 
ETC. SEFARATE EACH ENTRY BY A COMMA. FOR EXAMPLE ¢ Ne 24e1dyirir2 
P Ex 30r212x1v2si1 
PP Nx SOr122z19291 
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K X 
PLU 


22s 


to 
on 


26+ 
27s 
28, 


IS ANY OF THE FIRST FLOOR AREA CARPETED (1=YES OR 2=NO) ? 1 
ENTER CARPETED FIRST FLOOR AREA IN SQ. FT. ? 180 

INSULATED (1=YES QR 2=N0) ? 2 
IS ANY OF THE FIRST FLOOR NOT CARPETED (C1L=YES OR 2=NO) ? 1 
ENTER FIRST FLOOR AREA NOT CARFETED IN SQ.FT. ? 3463 

INSULATED (L=YES OR 2=NQ) ? 2 
ENTER UNINSULATED CEILING AREA (SQ,.FT.) ANI R-VALUE. SEFARATE EACH 
NUMBER RY A COMMA. IF THERE IS NO UNINSULATED CEILING AREA, ENTER 
AO FOR THE CEILING AREA AND A O FOR THE R-VALUE ? 070 
ENTER INSULATED CEILING AREA (SQ.FT.) AND R-VALUE. SEFARATE EACH 
NUMBER BY A COMMA. IF THERE IS NO INSULATED CEILING AREA, ENTER A 
O FOR THE CEILING AREA AND A O FOR THE R-VALUE ? 643%24 


ENTRY NOT REALISTIC * XTOTAL CEILING AREA DOES NOT EQUAL INSULATED 


S UNINSULATED CEILING AREA (WITHIN 10%). PLEASE REENTER LATA. 


ENTER UNINSULATED CEILING AREA (SQ.FT.) AND R-VALUE. SEPARATE EACH 
NUMBER BY A COMMA. IF THERE IS NO UNINSULATED CEILING AREA» ENTER 
A O FOR THE CEILING AREA AND A O FOR THE R-VALUE ? 070 
ENTER INSULATED CEILING AREA (SQ.FT.) AND R-VALUE. SEPARATE EACH 
NUMBER BY A COMMA. IF THERE IS NO INSULATED CEILING AREA» ENTER A 
O FOR THE CEILING AREA ANI A O FOR THE R-VALUE ? 543,24 
WINDOWS $ NUMBER OF LINES FILLED IN (1-45) AND DOURLE HUNG C1=YES 
OR 2=NO) ? Zyl 
ENTER WINDOW DATA AS FOLLOWS $: ENTER NIRECTION (Ny Sy E OR W)» WIDTH 
CINCHES)» HEIGHT (INCHES) » CONDITION (1% 2 OR 3)» GOOD STORMS (1=YES 
OR 2=NO)» NUMBER OF SAME IIRECTIONs CONDITION, ETC. SEPARATE EACH 
ENTRY WITH A COMMA. FOR EXAMPLE ¢ Ne 2@8r53s2rty93 
? GxrS6SeSlrviv2r1 
? Nx? 

36x 35x 3v1 vil 
Ne487S5S3rivivil 
Nxv48233rxlx192 
ExS4x33xleolvi 
Wr48sS3Grixvivi 
Wr 59 e SSy Pr 2y 
DOOR DATA ¢ HOW MANY LINES FILLED IN ? 2 
ENTER ROOR PATA AS FOLLOWS $ DIRECTION (Ny SG» E OR W)» WIDTH CIN 
CHES)» HEIGHT (INCHES)» CONDIIITION (ly 2 OR 3)» STORMS C1=YES 
OR 2=NO). SEFARATE EACH ENTRY WITH A COMMA. FOR EXAMPLE Ny 36>» 
B4Ayxvivi 
P $x 367847292 
P We72rB84e 10) 
WALL CONDITION NUMBER ? 4 
ENTER TOTAL OUTSIDE WALL AREA INSULATED ANID R-VALUE ? 670 
ENTER TOTAL OUTSIDE WALL AREA UNINSULATED AND R-VALUE ? 752,73 


VQ ad -a 


-y 


NO YOU WISH TO STORE INFORMATION UNTIL LATER (1=YES 2=NO) ? 2 
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TO DETERMINE THE ACCURACY OF THE COMPUTER RESULTS» COMPARE THE COMPUTED 
FUEL BILL TO THE ACTUAL FUEL BRILL. THE CLOSER THE MATCH THE MORE ACCU- 
RATE THE RESULTS. THE POTENTIAL SAVINGS INDICATED ARE FOR THE FIRST 
COMPLETE HEATING SEASON. POTENTIAL DOLLAR SAVINGS ASSUME THAT THE FRICE 
OF FUEL REMAINS THE SAME. MATERIAL COSTS VARY A GREAT TEAL AND SHOULD 
BE CHECKED LOCALLY. 


* KX K SURVEY QUESTION 8. * X X 

AVERAGE HOME TEMPERATURE IS 70 

YOU SHOULD LIVE AT A LOWER TEMPERATURE? 68 DEGREES FAHRENHEIT OR LESS. 
* k KX SURVEY QUESTION 7. XK * X 


HEATING EFFICIENCIES ASSUMED ARE : 65% OILy LF AND NATURAL GAS: 1002 
ELECTRIC» 60% COAL ANT 30Z% WOOD. 


YOUR FURNACE IS IN GOOD CONDITION - YOUR EFFICIENCY IS PROBABLY AS 
STATED, 


YOUR HEATLOSS IS 1111.7 THERMS GAS 
ASSUMING THAT YOUR FUEL COSTS ARE 25.00 CENTS FER THERM YOUR 
FUEL BILL SHOULT BRE ABOUT $ 277.971, 
OF THIS HEATLOSS 264 % IS TUE TO INFILTRATION LOSSES 
74 % IS DUE TO CONDUCTION LOSSES. 


* k X INFILTRATION LOSSES SHOULI) BE CONSIDERED FIRST * & X 
* * * SURVEY QUESTIONS 19. & 24. Kk XK X 


WINDOW DATA $ ONLY WINDOWS NEEDING WORK OR WITH TRIFLE GLAZED 
SEETEELLEEEEE SAVINGS GREATER THAN $2 ARE LISTED 


HEATLOSS = 12.1 THERMS GAS $ 3.03 (CONDUCTION) - BASEMENT 
HEATLOSS = 1.4 THERMS GAS $ 036 CINFILTRATION) - BASEMENT 
HEATLOSS = 177.1 THERMS GAS $ 44.28 (CONDUCTION) 
HEATLOSS = BO.1 THERMS GAS $ 20,02 CINFILTRATION) 
POTENTIAL 
FOTENTIAL FOTENTIAL SAVINGS 
SAVINGS SAVINGS IF WEATHER 
WEATHER IF WEATHER IF WEATHER STRIPPED 
WIDTH HEIGHT STORM STRIFFING STRIFFED STRIFPED AND TRIPLE 
DIRECTION INCHES INCHES NEEDED NEEDED (ONLY) AND STORM GLAZED 
B-EAST 30 12 YES NO $ Ol $ 064 $ PA 
B-NORTH 30 12 YES NO $ OL $ «64 $ 94 
SOUTH 63 a1 YES NO $ e12 $ 7424 $ 949A 
NORTH 36 33 NO YES $ 4,72 $ 4.72 $ S72 
WEST 39 33 YES YES $ 1.56 $ 4,41 $ 349 


eats COnd 6 00 SO) Cand ONDE NUDE NONE GED CEST CODE SFTP HOOT OREO F006 GIES SEES OPT CURD EAT Gman Ghd GAOO SEE DOTS NUE ONE GPE GENE SORT Cone 


TOTALS $ 6.43 $ 17.45 $ 30.00 


~ 


BASEMENT STORM WINTIOWS NEEDED 
USING ALUMINUM STORMS AVG. RETAIL FRICE = $ 24,00 


29 LINEAR FEET OF WEATHERSTRIFFING 


NEEDED FOR WINTOWS AVG. RETAIL FRICE = $ 2697 
2 STORM WINKOWS NEEDED 
USING ALUMINUM STORMS AVG. RETAIL FRICE = $ 100,00 
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KX KX SURVEY QUESTION 25. * Kk X 


DOOR DATA $ ONLY TOORS NEEDING WORK AKE LISTED. 


SEEGER 
HEATLOSS = 119.4 THERMS GAS $ 29.86 (CONDUCTION) 
HEATLOSS = 101.8 THERMS GAS $ 25.44 CINFILTRATION) 


POTENTIAL FOTENTIAL 
SAVINGS SAVINGS 
WEATHER IF WEATHER TF WEATHER 
WINTH HEIGHT STORM STRIFFING STRIFFED STRIPPED 


QIRECTION INCHES INCHES NEEDED NEEDED CONEY) AND STORM 
SOUTH 36 84 YES YES $ 16.70 $ 23.06 


TOTALS $ 16.71 $ 23.07 


20 LINEAR FEET OF WEATHERSTRIFFING 


NEEDED FOR DOORS AVG. RETAIL FRICE = $ 2200 
1 STORM DOORS NEEDED 
USING ALUMINUM STORMS AVG. RETAIL PRICE = $ 75.00 


* kK * SURVEY QUESTION 18. * XK X 

FOUNDATION INFILTRATION DATAS 

F$EEFELE FEET E TEES EE EE EA TE EE EE 

HEATLOSS = 3043 THERMS GAS $ 7.57 CINFILTRATION) 

FOUNDATION NEEDS SOME WORK: PARTICULARLY CAULNING 

CRACK LENGTH ASSOCIATED WITH SILL AND FOUNDATION [5 94 LINEAR FEET 
? TUBES OF CAULKING MAY BE NEEDED *xx AVG. RETAIL FRICE = $ 123.50 

POTENTIAL SAVINGS: 20.6 THERMS GAS $ 2014 

* * KX SURVEY QUESTION 24. * * X 

WALL INFILTRATION ATAS 

SESSETECELEEEEES ET EET EE 

HEATLOSS = 7968 THERMS GAS $ 14.94 CINFILTRATION) 

WALL CONIITITION IS GOOD, NO WORK NEEDED NO FOTENTIAL SAVINGS. 


CONDUCTION LOSSES SHOULD BE CONSIDEFEN SECOND, 
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Kk kK KX SURVEY QUESTIONS 6.922. & 23. % % X 


CEILING LATA 
FEE ETO RETEST 


HEATLOSS = 0 THERMS GAS $ 600 CUNINSULATETD) 
HEATLOSS = Jue THERMS GAS $ 13.96 CINSULATED) 
INSULATED CEILING AREA = 943 SQUARE FEET CURRENT R-VALUE = 24,0 


ADQITIONAL INSULATION NEEDED TO ACHIEVE AN R-VALUE OF ABOUT R= 33 

© SETTLED INCHES OF BLOWN CELLULOSE R=3,.7/IN. 

8 30 LE BAGS OF CELLULOSE AVG. RETAIL FRICE = $ 40.00 
YOROKHOK OR KOK KK 
ASSUME ONLY 3 AND. 6&6 INCH BATTS ARE EASILY AVAILABLE 


6 ROLLS OF 6.0 X 23 FIBER GLASS BATTS AVG. RETAIL PRICE 


$ 173.76 
WITH THIS FIBER GLASS ADKED TOTAL R-VALUE = 43.90 

VENTILATION REQUIREMENTS CASSUMES NO VAPOR BARRIER EXISTS) 

AKHOUT 12.8 SQ.FT. INLET AVG. RETAIL FRICE = $ 3.75 USING ATTIC VENTS 
ABOUT 1.8 SQ.FT. OUTLET AVG. RETAIL FRICE = $ 12.00 USING ROOF VENTS 
POTENTIAL SAVINGS: 14.0 THERMS GAS $ 3.99 

* K K SURVEY QUESTIONS 27. & 28. XK X xX 


WALL DATAS 
SFTETEEE ET 


KX KX WALL INSULATION STANDARG USED IS R-11ix xk xX 
* * KX TOTAL WALL R-VALUE STANDARD IS R-15 %* k xX 


HEATLOSS = 287.4 THERMS GAS $ 71.85 (CONDUCTION) 
TOTAL WALL AREA = 752 SQUARE FEET 
TOTAL WINKOW ANT DOOR AREA = 159 SQUARE FEET 


NET WALL AREA = w?2 SQUARE FEET 
100 “4 OF THE NET WALL AREA IS NOT INSULATED R-VALUE = 349 
ADQOITIONAL INSULATION NEENEDR TO ACHIEVE AN R-VALUE OF ABOUT R=15 
3eS INCHES OF BLOWN CELLULOSE R=3.7/IN. 
19 50 LE BAGS OF CELLULOSE AVG. RETAIL FRICE = $ 94.00 


POTENTIAL SAVINGS UNINSULATED WALLS? 204.4 THERMS GAS $ %Si1.11 
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* K KX SURVEY QUESTIONS 12.715.%16.717.720. & 21. * &K X 


RASEMENT DNATA 3 
PERE Rt ea abt 
HEATLOSS = 184.4 THERMS GAS $ 46.60 (CONDUCTION) 


OF THE HEAT LOST TO YOUR BASEMENT 72% IS LOST THROUGHTHE EXFOSED FART 
OF THE BASEMENT WALL» 18% IS LOST THROUGH THE FART NOT EXFOSED AND 9% 
IS LOST THROUGH THE BASEMENT FLOOR, 


IF YOU INSULATE THE BASEMENT WALLS» THE HEAT LOST TO THE EASEMENT IS 3 


INSULATION TYFE CALCULATED HEATLOSS FOTENTIAL SAVINGS 

a he ae THERMS GAS DOLLARS THERMS GAS DOLLARS 
R- 4 WALL 134.0 $ 33.51 Joo 4 $ 13.10 
K-11 WALL 115.0 $ 28.75 71.4 $ 17.85 


HOT WATER TATA 
SFEEELELETE ET EE 


FOR THE 1 INDIVINUALS OCCUFYING THE HOME 
THE HOT WATER COSTS PER YEAR ARE ABOUT 


63 IF ELECTRIC AT $,03/KWHR 

20 IF NATURAL GAS AT $.25/THERM 
35 IF LF AT $.40/GALLON 

28 IF OIL AT $,47/GALLON 


+ th tt th 


IF YOU WISH ADDITIONAL INFORMATION CONTACT? 

WESTCAF HOUSING AND ENERGY» GLENWOOD CITY, WI. 715-265-4271. 
UW RIVER FALLS» FHYSICS/ENERGYs RIVER FALLS» WI. 715-425-3196. 
WISCONSIN OFFICE OF STATE FLANNING AND ENERGY 

MALIIISON,s WI. 508-264-6850, 


SSFFELEFETE SETHE AEE ET ESTA EE EEE EE ESSE EEE TERETE EEE EE ER EEE EEE EEE ES ESTEE EEE EE 
TOTAL FOTENTIAL SAVINGS: ATS 02 THERMS GAS $118.80 
Be Oe a | | | DC AT a it if: 


¢ 


Enter two (2) digit code for desired ortion 3 
O1 Home enersy sudit O02 Outreut stored audit information 
95 Stor 

“~N9 


HEATLOSS RUN TERMINATED. 
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A DECISION SUPPORT SYSTEM TO ASSIST 
IN CONTAINERBOARD LOGISTICS MANAGEMENT 


PETER DIGIAMMARINO AND RICHARD SCHWARTZ 
AMERICAN MANAGEMENT SYSTEMS, INC. 
SAN MATEO, CALIFORNIA 


ABSTRACT 


Management decision-making must be responsive to changing 
economic conditions, dynamic internal business circum- 
stances, and an expanding set of operational and strategic 
issues relevant to business policy-making. Decision-making 
in this environment requires timely access to accurate and 
complete information pertinent to specific business situ- 
ations. Meeting this requirement is complicated by a nar- 
rowing time frame in which highly volatile data must be 
organized and analyzed before it can be assimilated into 

the decision-making process. Effective management of 
containerboard production and distribution requires an 
information system that supports decision-making in all 
phases of business activity: operational control, manage- 
ment control and strategic planning. The Brownboard Order 
And Rollstock Distribution System (BOARDS) integrates manage- 
ment science and operations research with advanced computer 
technology and human decision-making to support demand-based 
production planning in the corrugated shipping container 
industry. 


American Management Systems, Inc., a management consulting 

and system development firm, developed BOARDS for the Shipping 
Container and Containerboard Marketing Division of Weyerhaeuser, 
a company principally engaged in the manufacture, distribution 
and sale of forest products. BOARDS operates on a dedicated 
Hewlett-Packard 3000 Series II computer with 512K bytes of main 
memory. Nine distinct IMAGE data bases constitute the system's 
foundation. Over one hundred BOARDS functions written in COBOL, 
SPL and FORTRAN have been aggregated into six integrated sub- 
systems. Most of the system was installed in the fall of 1978; 
further development is underway and will be installed early in- 
1979. 


A-84.1 


INTRODUCTION 


The corrugated shipping container industry is highly sensitive to 
dynamic market and economic conditions. Increased competition, tech- 
nological advances that have yielded attractive substitutes, and 
tightening environmental regulations are factors contributing to the 
rising production costs and unstable demand facing the industry. When 
the lumber business is prospering, the integrated forest products manu- 
facturers (those companies that make lumber, brownboard and boxes) run 
their containerboard mills at full capacity in order to consume prodigious 
quantities of wood chips. Flooding the market with containerboard in 
periods of depressed box demand results in excess containerboard inven- 
tories and narrowing profit margins. Containerboard inventory distri- 
bution, in addition to supply considerations, is also an integral part 
of sales and profit performance. 


The corrugated shipping container producers have every incentive to 
adjust operating policies and planning strategies to meet the challenge 
of achieving production capacity and improving profit margins. Alterna- 
tive means of adjusting the market conditions are to control production 
of containerboard at the mill; discover ways to increase demand; or 
institute mechanisms for supply planning, demand forecasting, and mill 
scheduling which result in inventory levels that are responsive to actual 
consumer demand and that are economically justified. 


EXAMINING THE ALTERNATIVES 


Mill production of containerboard typically runs in cycles; production 
of light-weight grades followed by heavy-weights and back to light-weights. 
Gradual increments in grade/basis weight production maintain an efficient 
cycle whereas irregular changes require substantial machine set up time, 
are disruptive, and drive up production costs. Extreme fluctuations in 
box demand do not coincide with an orderly, efficient production cycle. 
Satisfying uneven fluctuations in demand by increasing or decreasing pro- 
duction volume, while maintaining an efficient grade cycle, adds to the 
high operating cost of containerboard production. Therefore, production 
control mechanisms are expensive and undesirable. Even if production is 
responsive to demand, situations may still occur such that it would be 
cost effective to slow or shut down the mill; but generally only as a 
last resort. 


Shipping container manufacturers have campaigned vigorously to in- 
crease demand for their product. As evidence of this, the integrated 
companies have chosen to enter markets for low volume, specialty containers. 
New foreign markets are also being explored. The continuous growth in 
demand for corrugated boxes that prevailed during the 1960's at 5.6% per 
year slowed to about 3% per year in the early 1970's and is optimistically 
expected to equal the growth of the U.S. economy in the long run (Business 
Week March 13, 1978). Efforts to generate increased demand for shipping 
containers continue, but are not a practical long-term solution to pro- 
blems associated with containerboard inventory management under volatile 
market conditions. 
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A practical long-term strategy is to achieve improved management of 
existing facilities in response to consumer demand. The objectives are 
to minimize inventory stockpiling and to avoid lost sales due to poor 
inventory distribution. This is accomplished if each corrugated box shop 
is supplied with, or has access to, sufficient and specific quantities of 
brownboard needed to satisfy existing and forecasted customer orders. Container- 
board Logistics Management is responsible for achieving this demand/supply 
babance. The difficulty associated with establishing demand-based pro- 
duction and planning policy is that large quantities of information must 
be assimilated into the logistics management decision-making process. 
Fluctuations in demand must be accurately monitored for each box shop and 
market region; up-to-date inventory levels at the box shops and the mills, 
and quantities in-transit must be known at all times; and mechanisms to pro- 
cess, track and assess the status of containerboard orders must be in place. 


A system that provides this information must support containerboard 
logistics decision-making in all phases of management activity: operational 
control, management control and strategic planning. Within each type of 
activity, the system must support decision-making that ranges from struc- 
tured (such as order entry, inventory control, consumption forecasting, and 
pricing) to semi-structured (such as mill scheduling, simulating policy 
decisions to set target weeks of containerboard inventory at the box shops, 
and demand/supply planning analysis). 


A_FRAMEWORK FOR CONTAINERBOARD LOGISTICS DECISION MAKING 


The usefulness of such a system extends beyond the realm of management 
control. Day-to-day operational support to the box Shops and containerboard 
mills is also achieved. Order entry, containerboard production, shipment, 
Invoice and receipt transaction processing facilitate ongoing activities at 
distributed sites while simultaneously supplying a central pool of management 
information. Decisions to contract for additional containerboard orders or 
to purchase additional containerboard are based on better and more complete 
information by providing box shops direct access to the system. 


A system to manage a demand-based production strategy must be capable 
of accurately capturing and monitoring consumption forecasts and converting 
those forecasts into orders that can be filled economically. Access to 
weekly box shop consumption forecasts, current on-hand and in-transit quan- 
ities, and outstanding orders provides containerboard logistics management 
with the information required to determine the grade and quantity of brown- 
board to order for each box shop in the upcoming weeks. Mill production 
rates, warehouse inventory levels, and trade agreement balances provided by 
the system are also used by management to help make economical decisions 
when placing orders. 
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A system to capture, store, process, and report information in a 
timely and usable manner must be responsive to dynamic market conditions 
to justify its use in any market. It is intuitively appealing to posit 
that a well organized demand-based production strategy will function well 
under any market conditions, although it is especially cost effective in 
tight markets. Using the system to simulate alternative supply planning 
strategies in accordance with projected economic circumstances further 
contributes to its usefulness in diverse market situations. 


American Management Systems, Inc., a management consulting and systems 
development firm, has developed the Brownboard Order And Rollstock Distri- 
bution System (BOARDS) for the Shipping Container and Containerboard 
Marketing Division of Weyerhaeuser, a company principally engaged in the 
manufacture, distribution, and sale of forest products. BOARDS provides 
information services for all phases of containerboard logistics management 
activity: operational control, management control, and strategic planning. 
The functions of BOARDS map well into the Framework for Management Infor- 
mation Systems developed by Gorry and Scott Morton (Gorry and Scott Morton 
1971) from Anthony's taxonomy of management activity (Anthony 1965) and 
Simon's continuum of managements' approach to decision-making (Simon 1960). 
Figure 1 shows the array of decision-making activity supported by BOARDS 
within this framework. 


To the extent that BOARDS handles routine processing needs (e.g., order 
entry, inquiry and update, and inventory control) it is a conventional 
management information system. These functions are structured in the sense 
that they are based upon well understood, easily automated processes and 
require limited human intervention. The rest of BOARDS supports decision- 
making that is much less mechanical. Order sourcing, mill scheduling, box 
shop inventory replenishment and demand/supply planning are examples of 
functions that require relevant information to be processed and acted upon 
differently depending upon conditions that are so dynamic and diverse that 
they cannot be effectively automated. In these cases, BOARDS is designed 
to assist the decision-maker by providing rapid access to timely information 
in the format most appropriate to the situation at hand. As the first two 
columns in Figure 1 depict, some BOARDS functions assist institutional 
decision-making; i.e., decision-making required to manage everyday business 
situations. Conversely, some BOARDS functions aid in ad-hoc decision-making 
as shown in the third column of Figure 1 (Donovan and Madnick 1977). BOARDS 
is, therefore, more than a conventional management information system and 


is appropriately termed a Decision Support System (Keen and Scott Morton 1977). 
BOARDS OVERVIEW 


The distribution of containerboard is illustrated as a cyclical flow 
in Figure 2. Contemporary containerboard distribution systems are driven 
by mill production and containerboard supply capabilities. With BOARDS, 
however, the cycle starts with consumption forecasts provided by the box 
shops. This input is based upon actual sales agreements, outstanding orders, 
seasonal trends, and prevailing market conditions. Containerboard Logistics 
(C/L) management has the option of scaling forecasts up or down, either 
across all box shops and products or by individual box shop, based upon its 
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Figure 1 
BOARDS-supported Decision Making Activity 
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perception of market trends and prevailing or projected economic circum- 
stances. Based upon these forecasts, and knowledge of unfilled orders and 
current inventory levels, C/L generates mill orders for containerboard. 
Taking into account current mill production schedules, in-transit times, 
and production capacities, these orders are then sourced and scheduled at 
the mills. Mills produce what is ordered, accumulating inventories until 
shipments are made. The containerboard is then in-transit until it is re- 
ceived by the box shop where it is stored and utlimately consumed. 


BOARDS serves two fundamental purposes in this distribution cycle, also 
shown in Figure 2. Each activity in the cycle is recorded by BOARDS as it 
compiles a reservoir of information and assists in reconciling operational 
discrepancies. Correspondingly, BOARDS is a source of information. The 
mills may examine their production backlog, and the box shops can determine 
how much brownboard is in-transit, how much is yet to be scheduled, and so 
forth. C/L may request aggregate or detailed information concerning the 
current status of containerboard flowing through the system. 


BOARDS operates on a dedicated Hewlett-Packard 3000 series II computer 
with 512K bytes of main memory. Nine distinct IMAGE (Hewlett-Packard's data 
base management system) data bases constitute the system's foundation. Over 
one hundred BOARDS functions are aggregated into six integrated subsystems: 
Order Processing, Production Planning and Mill Scheduling, Inventory Control, 
Trade Tracking, Planning and Material Balance, and Mill Price Difference 
Reporting as depicted in Figure 3. BOARDS supports management decision- 
making at Weyerhaeuser headquarters in Federal Way, Washington, and at 31 
box shops and four mills located across the country. BOARDS has added flex- 
ibility since it interfaces directly with various computer systems located at 
the four mills and indirectly via magnetic tape transfer with existing computer 
systems running on Honeywell equipment at company headquarters. Figure 4 shows 
an overview of BOARDS hardware configuration and telecommunications network, 


A detailed example of two integrated BOARDS functions, Box Shop 
Replenishment and Mill Scheduling, illustrates the system's potential to 
monitor and control demand-based production. 


BOX SHOP REPLENISHMENT 


The Box Shop Replenishment (BOXREP) function, as shown in Figure 5, 
retrieves weekly consumption forecasts from the Planning Data Base, current 
on-hand and in-transit quantities from the Inventory Data Base, and out- 
standing orders from the Order Master Data Base. This data is used to 
automatically determine the grade and quantity of containerboard to order for 
each Box Shop in the upcoming weeks. The C/L Box Shop Service Representative 
interactively specifies input parameters which include whether to use 
economic adjustment factors that account for recent changes in the market, 
whether to use target or minimum inventory levels, and report specifications, 
In-transit times between the mills and the box shops are also used in com- 
puting order quantities and shipment dates. Default parameters are supplied 
from the BOARDS Master Table Data Base upon user request. The results of 
the computations are stored on the Want-to-Ship Data Base. Quantities stored 
in this data base represent the amount of containerboard that should be 


placed on order by box shop and week for the next six weeks in order to 
meet projected consumer demand. 
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BOX SHOP REPLENISHMENT FUNCTION 


| BOXREP results can be examined in any of three ways. The first out- 
put is in the form of standard reports. The reports show Want-to-Ship 
quantities in varying levels of detail and aggregation. BOXREP also 
produces an exception report that shows current and projected crisis con- 
ditions by week for each box shop and product (for example; inventory levels 
are projected to fall below minimum, or expected receipts are greater than 
capacity). The second mechanism for inspecting Want-to-Ship quantities 
shows a box shop's proposed shipments in the form of a purchase order on a 
CRT. The information is displayed, can be revised and, optionally, con- 
verted into an open purchase order. The quantities stored on the Want-to- 
Ship Data Base are automatically adjusted to account for containerboard 
that is placed on order. Lastly, C/L management or users at the box shops 
can examine the current contents of the Want-to-Ship Data Base. A BOARDS 
inquiry function interactively displays the proposed shipment quantities 
by box shop, product and ship week, adjusted for orders already placed. 


Proposed shipments are never automatically converted to open orders, 
since many non-quantifiable factors affect the decision to place an order. 
Surrounding economic conditions can drastically alter the usefulness of 
proposed shipments. Therefore, manual involvement is critical. Support 
_ for this sort of semi-structured decision-making is what distinguishes 
BOARDS from conventional management information systems. The utility 
of BOXREP is in assisting order generation rather than in automating it. 


While BOXREP is engaged in information retrieval, calculations and 
reporting, the user is free to execute other BOARDS functions since the 
BOXREP processing is performed in batch mode. BOXREP can also be run 
iteratively to test the impact of alternate consumption and inventory 
adjustment factors, policy variables or target inventory levels without 
interfering with the active contents of the Want-to-Ship Data Base. When 
a desirable set of calculations has been achieved the data base can then 
be updated. BOXREP logic is configured such that several BOXREP processes 
can be under way simultaneously as long as only one is updating the data 
base. This flexibility has been provided to enhance BOXREP's utility as 
a planning facility in addition to its use as a production system. 


MILL SCHEDULING 


Mill scheduling, as shown in Figure 6, consists of three functions: 
Trim Input, Trimming, and Mill Order Maintenance. Containerboard Logistics’ 
mill schedulers use these functions to specify the quantity, sequence, and 
date in which ordered containerboard is to be produced at each mill. 
Their objectives are to maximize production efficiency and minimize trimming 
loss. The scheduler uses the Trim Input function to interactively select 
unscheduled purchase orders from the Order Master Data Base for production 
at the mills. The retrieved orders are displayed on a CRT as a “Trim Input”. 
The scheduler can modify the input as desired to obtain a tentative set of 
orders to be scheduled together at a mill. Once satisfied with the Trim 
Input, the scheduler specifies a trim algorithm, either the linear programming 
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model or the heuristic program, and the Trim Input is passed to the Trimming 
function via a temporary file. The Trimming function executes the selected 
trim algorithm, stores the results in the Mill/Trim Order Data Base, and 
prints the results, referred to as a Trim Set. The Trim Set shows the near 
optimum positions in which to place cutting knives in order to trim the 
maximum number of ordered widths per containerboard roli and minimize the 
trim loss. 


The Mill Order Maintenance function converts a Trim Set into a Mill 
Order. If the Trim Set is satisfactory, the scheduler can interactively 
convert it by assigning a production date and sequence number, and requesting 
that the production schedule be forwarded automatically to the mill. Alter- 
natively, the scheduler can manually adjust the Trim Set to account for factors 
not considered by the trim algorithm. Lastly, the scheduler can discard the 
Trim Set altogether. In this case, the scheduler either modifies the 
original selection criteria or compiles an entirely new set of criteria to 
construct a new Trim Input and begin the trim cycle again. Note, once more, 
the critical role of human involvement in BOARDS supported decision-making. 
The scheduler is better prepared than a totally automated process to deal with 
day-to-day peculiarities and priorities. Therefore, the Trim Set is never 
automatically converted into a Mill Order. 


It may require several iterations before the scheduler arrives at a 
Satisfactory production schedule. Although the objectives are well defined, 
it is technically infeasible to completely automate the scheduling process. 
BOARDS provides utility in that it enables several input combinations to be 
analyzed in the form of production schedules. The limiting factor is time. 
To examine every possible set of input combinations is tedious, time con- 
suming, and costly. BOARDS facilitates this complicated decision-making 
process by enabling more alternatives to be considered through functions 
that are efficient, fast, and easy to use. 


CONCLUSION 


BOARDS provides decision support in all phases of containerboard 
logistics management: operational control, management control, and 
strategic planning. BOARDS is distinguished from conventional management 
information systems in that it integrates automated processes of manage- 
ment science and operations research with routine data processing and 
human decision-making. Advanced technologies, in the form of data base 
management and distributed on-line user access, are brought together to 
form a system that satisfies the long term information processing needs 
of Weyerhaeuser's containerboard logistics management. Its goal is to 
control containerboard inventories and to improve inventory distribution 
by supporting demand-based production planning in an industry highly 
sensitive to market conditions and economic circumstances. 
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CORPORATE MODELING 
DESIGN & IMPLEMENTATION 
OF FINANCIAL PLANNING SYSTEMS 
FOR THE HP 3000 


FORESIGHT is a computerized financial analysis, planning and modeling language 
that addresses the numerous problems faced by managers. It was the first 
User-oriented interactive financial planning language to be placed on a computer 
system. It has been in use for over a decade and has been continually upgraded 
and modified in responce to changing business trends and computer technology. 


FORESIGHT is a part of United Computing Systems, Inc., Business Information 
Products and is backed by its parent company, United Telecommunications, Inc. 

with assets of $3.5 Billion. As a consulting oriented firm, UCS-BIP has extensive 
technical, training and consulting staff to assist the user through numerous 
regional offices - Atlanta, Houston, Kansas City, Los Angeles, Minneapolis, 

New York City, San Diego and San Francisco. 


FORESIGHT's command vocabulary is based on everyday business language. Data 
entry is simple and previous computer experience is not required. Your attention 
is focused on the report, not the computer. 


In addition, FORESIGHT can be used at any origanizational level, from the smallest 
cost center to the largest multi-national corporations. It was developed for 
business people by business people. It readily adopts to your particular require- 
ments and can accommodate each departments unique operation. Management reports 
or financial models can be easily adjusted to reflect changing business conditions 
or organizational evolutions. 


FORESIGHT can be purchased or leased for your HP 3000. 
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Planning for the future, whether that future is the next quarter, year 
or 5 or 10 year period, is a basic concern of every business manager. 
Management has to make decisions on corporate analyses, planning and 
control. All within limited time periods. And - not only is the manager 
expectedto have access to the required information, but he is expected 


to be able to report on it, and present it in an understandable form. 


Management has need to test assumptions in relation to planning, 
control or financial models without risking capital or resources. 
The ability to explore alternatives, to ask "What if?" is more 
important today than ever before. 
-What if my sales should increase by 15% ? 
“What if material costs should rise 5% ? 


-What if I should have to make a substantial capital 
outlay in the third quarter? 


Before we look at an example, let's take a minute to understand how 
information is handled using Foresight. Foresight is based on the concept 
of a matrix. A matrix being made by the intersection of a series of 
lines and columns (both variable). The intersection of which houses a 
data element (either directly input of calculated). The intersection of 


a line and column we call a cell. 
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Specifications - 5500 cells 


100 columns 
1000 lines 





To this matrix, a number of descriptive fields are added: 


January 1, 1977 Eastern Division 


1977 Planned Product Sales 
Cost of Goods Manufactured 
Profit and Loss Statement 


Month end Total 
January Fiscal Year 
1977 1977 


we tee 
—_— 
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Let's look at an example which will illustrate some of these needs. 
To help with the illustration, we will look at the Willett Manufacturing 
Company which has two product lines (we'll call them A and B). Willett 
markets these products to both the commercial and residential housing 
markets. With the exception of sales which is segmented into two 
geographical divisions, all functions are centralized within the company 
(attached). 
The three individuals involved in this planning cycle are the: 
- Director of Marketing 
- Manager of Production 
- Director of Finance 
As a marketing driven company, the director of marketing has developed 
a sales forecast which is submitted on a monthly basis for the period 


January to December. 


Easter Region 


District l 


Product A 135 175 225 265 310 310 

265 225 225 225 175 135 
Product B 105 95 93 95 115 125 

135 135 135 120 115 155 

District 2 

Product A 180 180 180 180 180 180 

180 180 180 180 180 180 
Product B Incrementing by 5% per month based on a 1976 year 


end average of 100 units per month. 
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In addition, marketing has determined the price per unit for 
product A will be $1475 per unit; for product B - $1700 per unit with 
a price increase to $1800 per unit starting in July. 

The first statement we need to look at is planned product sales 
(Exhibit 1). We have taken input from the Director of Marketing and 
produced a report based on the various line items and calculations he 
wished to see. 

Based on these results the Manager of Manufacturing determined the 
necessary lead time for production. The Director of.Finance concurred 
for the indirect cost and overhead. From this input, a cost of goods 
manufactured report was produced (Exhibit 2). 

At the Finance Director's level, most of the detailed information 
is not required. So his profit and loss report is produced (Exhibit 2) 
using only those totals he wishes to see and including additional 
corporate level items of interest (Depreciation, General and Adminis- 
trative expenses, Bonuses). 

Now that we have a full set of basic reports for the Eastern Division, 
what about the Western Division? As both divisions have the same 
organizational structure, the only change from the Eastern division is 


in the sales estimates - 


District l 
Product A 160 210 270 320 370 370 
320 270 270 270 210 160 
Product B 100 90 90 90 105 120 
130 125 130 110 110 145 
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District 2 


Product A 190 190 195 195 195 225 
235 275 275 260 260 250 


Product B Incrementing by 10% per month based on a 1976 year 
end average of 100 units per month. 


A similar set of reports is produced (Exhibits 4-8). 

From these two sets of divisional outputs, a series of higher level 
reports can be easily attained.By the use of the foresight conm.lidate 
and merge command a consolidated profit and loss in statement produced 
(Exhibit 9). 

At higher corporate levels a variety of additional reports may be 
required using the existing data base of information. A comparative 
profit and loss statement is produced using the consolidate and select 
command (Exhibit 10). At each higher level, additional logic an be 
added to specified results extracted from the original data base 
utilizing: 'oresight's format file capability. 

For the final presentation to the President of the Willett 
Manufacturing Company, the Finance Director decided to use Presight's 
andvanced report writer capability to produce a more finished report 


(Exhibit 11). 
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PRESENTATION TITLE: IDIMS - HP3000 Based Digital Image Processing 
INDIVIDUAL (S) NAME(S) : Paul Polk 


ADDRESS : ESL Inc. 
P.O. Box 6000 
Sunnyvale, CA 94086 


ABSTRACT: 


The field of digital image processing has grown dramatically in the last 
Six years, largely due to the increasing use of NASA's LANDSTAT satellite 
for resource inventories, mineral and petroleum exploration, and urban 
planning use. This presentation will describe ESL's HP3000 based image 
processing system - IDIMS; some of the above mentioned applications areas 
ESL has been involved with; and the special purpose peripherals ESL has 
interfaced to the HP3000. The special peripherals include an interactive 
color display, an array processor, 300 Mbyte disks, electrostatic printer/ 
plotters, and high speed, high density tape drives (1600/6250 bpi, 75 ips). 
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ECONOMETRIC MODELLING ON AN HP 3000 


John Eaton 
London Business School 


INTRODUCTION 


Econometric modelling, particularly of national economies, has become 
something of a growth industry during the 1970s. The current publi- 
cally available models of national economies grew out of research 
projects in universities and other research - based organizations in 
the late 1960s and early 1970s. This development was made possible 
by several factors, of which one of undoubted significance was the 
advent of the electronic computer in the social sciences. For econo- 
metric modellers , computers removed the tedium and effort in storing 
and manipulating the data required, in estimating the relationships 
that make up the model, and in solving the model for forecasting and 
Simulation purposes. 


This paper discussed the implementation of a large econometric model 
of the UK economy on the HP 3000 system at the London Business School. 
Though the discussion in this paper is entirely in terms of modelling 
national economies, modelling techniques such as these are finding 
increasing application in many large organizations. Thus many large 
corporations maintain econometric models of the market environment 

in which they operate, in most cases taking as input the outputs from 
the large national models of the type discussed in this paper. The 
purpose of such models from the corporations’ view is to enable them 
to evaluate alternative strategies in the simulated environments with 
respect to factors determined by their decisions, and those determined 
externally by government or their competitors. 
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The next section provides a general introduction to econometric 
modelling, and the one following introduces the LBS model of the 

UK economy. The remaining three sections then discuss the imp lemen- 
tation of this model on the HP 3000, in terms of, an on-line data- 
base of macro-economic variables; the model estimation process; and the 
model solution process for forecasting and simulation purposes. 


ECONOMETRIC MODELLING OF A NATIONAL ECONOMY 

Econometric models, like any other mathematical models, are intended 

as mathematical repreentations of the significant characteristics of 

the system being modelled. In the case of a model of a national 
economy, the relationships that go to make up the model represent 

the flows or levels of real and financial resources within the economy, 
and between it and other economies. The relationships may be of three 
types. Accounting identities, which are of little technical interest, 
but which are necessary to complete the system; technical relation- 
ships, which usually represent institutional or administrative activites 
(for example, computation of tax yield, given information as to rates, 
income groups, etc); and finally, behavioural equations, which repre- 
sent the behaviour of some specific economic activity (for example, 

the level of imports of fuel, or the rate of inflation). In general, 

it is these behavioural equations which require the modellers time, 
effort and skill, though in the majority of current models they comprise 
less than half of the equations in the model. 


Within each behavioural equation in the model the variables appearing 

on the right-hand side of the equation (the independent or explanatory 
variables) determine the systematic variation in the variable on the 
left-hand side of the equation (the dependent variable). It is axiomatic 
that in a behavioural equation there will be some residual, random 
variation in the dependent variable which cannot be explained by any 
combination of systematic variables which have a meaningful economic 
interpretation. Thus an econometric model is composed of stochastic, 
statistical relationships; it is not an exact model (though for fore- 
casting and simulation purposes it is usually treated as though it were). 
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A variable which appears as the dependent variable of one equation 
may well appear as an independent variable in another equation in 
the model. Econometric models are usually therefore systems of 
simultaneous equations, though often they may be broken down into 
one or more blocks of simultaneous and recursive equations. 


Furthermore, it is highly likely that some of the equations will 

be non-linear in the variables, so that for forecasting and simu- 
lation purposes we are faced with the solution of a system of non- 
linear simultaneous equations. It is impossible to model the entire 
economic environment; some factors are not modelable (for example, 
determination of government policy variables), or are infeasible 

for modelling by an individual group (for example, the world economy, 
though I will return to this example later). The basic aim is to 
model those factors which are significant in terms of the movement or 
Management of the national economy. In order to be able to solve 
the model for future periods, we must have values of these variables 
determined outside the model, and of the parameters of the equations 
that go to make up the model. The variables whose values are deter- 
mined by solution of the model are known as variables endogenous to 
the system. Those variables whose value must be known in order that 
the system may be solved are known as exogenous. The exogenous 
variables may be further sub-divided into those that are purely 
exogenous (typically government policy variables), and those, known 
as predetermined variables, which are defined as equal to the value 
of endogenous variables in periods previous to that for which the 
model is currently being solved. 


The original, and still the major purpose in constructing models of 

a national economy is to facilitate the evaluation of alternative 
government policies for the management of the economy. Forecasting 
initially entered the picture as a means of model validation; that 

is, to demonstrate that the model is capable of accurately replicating 
the systematic behaviour of the real economy that it purports to 
represent. In an on-going context, forecasting has a crucial role 

to play in keeping the model on track. But the rationale for econometric 
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modelling as opposed to other forecasting methods is that it enables 
us to consider and assess alternative government policies ona 
consistent, rigourous basis. Thus, although the public face of the 
major modelling groups appears in the regular forecasts produced by 
their models, in practice, much more effort and interest will be 
found in the alternative strategies for government policy that are 
evaluated. 


Building a model in the first place is relatively simple as compared 
with the challenge of keeping it operational on an on-going basis, 
learning from it, and developing it as the economy itself and 
economists’ understanding of it change. In an important sense, 
modelling a national economy can be viewed as a continuous exercise 
in learning by doing. And it is an important part of the make-up 

of a modeller that he is able to learn from the environment he is 
modelling, and adapt his perception of the workings of the economy 
and his model of it accordingly. Some would argue that there was 

a time at the beginning of the 1970's when econometric modellers 

were in danger of being swept away by their use of computer technology, 
and of becoming over confident in the capabilities of themselves and 
their models. However, the oil-crisis and resultant world inflation 
provided a salutory shock to modellers everywhere, not only about the 
tru capabilities of their models, but also about some of the perhaps 
overlooked characteristics of the environment they were attempting to 
model. 


THE LBS MODEL OF THE UK ECONOMY 

The parentage of the LBS model goes back to the mid-1950's, when 
one of the leading American modellers, Professor Lawrence Klien of 
the University of Pennsylvania, visited Oxford University. Klien 
gathered together a small team of British graduate students, with 
whom he constructed the first econometric model of the UK economy, 
using annual data. Valuable though this first model was as a 
research exercise, possibly its greatest contribution lay in high- 
lighting what needed to be done in order to construct a fully 
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operational model of the UK economy. One of Klien's team on this 
first model was Jim Ball, who in 1965, was appointed Professor of 
Economics at the then newly founded London Business School (in 1971 
becoming Principal of the School). Since that first exercise, he 
had focussed his research efforts on assembling the basic building 
blocks for an operational UK model based on quarterly data. 


Shortly after joining the LBS he assembled a new model, from which 
the first forecasts were published towards the end of 1966. Since 
this time the LBS model has been continuously maintained and 
developed, and has been used to produce forecasts of the UK economy 
on a regular basis. The project received a major boost in 1967, 

when it was funded for the first time by the Social Science Research 
Council, whose generous support has continued to the present day. 

In 1976 a consortium of twelve major UK organizations was formed 

to support the Centre for Economic Forecasting at the LBS, which 

took over responsibility for the model, with Terry Burns as its 

first director. In addition to participation in forecast meetings 
with members of the staff of the Centre, members of the consortium 
also gained access to the data base, estimation programs and forecasting 
system maintained by the Centre. Thus, in addition to the ten full- 
time and four part-time staff of the Centre, who are engaged in 
maintaining the data-bank and the model, production of the basic 
control forecasts, and a range of research studies using the model, 
there is also a group of practising economists and forecasters making 
use of the system within their own organizations. 


The LBS model from which the first forecasts were published in 1966, 
comprised only 25 equations; the current model is made up of over 

300 equations. Although this is not as large as some of the models 

of the US economy, size is not necessarily a criteria of excellence. 
An operational model of a national economy does have to grow to a 
considerable size, simply in order to be able to adequately represent 
the detail of government policy options (i.e. detailed tax rates, 
expenditure patterns, financial behaviour, and so on). But increasing 
size brings with it problems of comprehension and management of the 
model, as the larger the model, the more unlikely it is that any 
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Single person is able to understand all the interactions of the 
complete model, 


The computer system requirements of an econometric model can be 
considered in three parts. A data base containing the historical 
data from which the relationships in the model are to be estimated, 
and two software packages, a statistical estimation program and a 
model solution/simulation program. Originally, the LBS system was 
implemented on a large-scale batch-processing machine (an IBM 360/65, 
located at University College, London University), and accessed by 
means of an rje terminal. However, this did not provide ideal 
support for either modellers or forecasters. In addition to the rje 
link to the 360/65, the LBS has operated an HP 2000 timesharing 
system since 1972 primarily providing a student computing service. 

In the mid-1970s a simple forecasting system was implemented on 

this system, with two objectives in mind. First, to examine to what 
extent on-line access and interactive processing might better support 
the modellers and forecasters needs. And second, to aid in the 
determination of the true computer system needs of the modelling 

and forecasting system. Nevertheless, although it was Clear that 

the system was more supportive of the modellers and forecasters needs 
than a batch system, the HP 2000 could not cope with the workload. 

In 1977, the LBS installed an HP 3000 Series II to provide computing 
services to all its research activities, including the Centre for 
Economic Forecasting. The entire modelling and forecasting system 
has now been implemented on the 3000, exploiting the on-line interactive 
capabilities of the system. 


THE MACRO-ECONOMIC DATA BANK 





The macro-economic data base provides modellers and forecasters with 
access to the basic raw material for their studies; the time-series 
recording the detailed movements in the national economy. At its 
simplest such an on-line data-bank is a source of data for information 
purposes, providing the answers to queries as to the level or movement 
in particular variables, or the input for tabular or graphic reports. 
However, its crucial role is to provide the raw material for the 
modelling and forecasting processes, for which it must be interfaced 
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with the estimation and solution/simulation systems. 


Three macro-economic data-banks are implemented on the HP 3000 at the 
LBS the major one being that containing quarterly data from the mid- 
1950s to date on slightly more than 1000 economic variables relating 
to both the UK and world economy. In addition there are smaller 
data-banks containing annual and monthly data respectively on the 
major variables. These data banks are structured as KSAM files 

with a standard structure applied to other data-banks at the LBS, 

in particular, a data bank containing stock market data on all UK 
quoted companies since the mid-1950s. The detailed structure of the 
LBS KSAM data banks is set out in Appendix A. 


The main data bank is updated on-line as new data is released by 
government and other agencies. Unfortunately, in the UK the govern- 
ment's statistical service is unable to provide data immediately 

in machine-readable form (only about a month late), so that the 
majority of the data is entered manually from press releases. A 

small suite of programs has been developed (in Fortran, using the 

KSAM intrinsics) to carry out the standard data management functions 
on-line or in batch as appropriate. Thus, functions to enter update, 
modify, and list specific variables may be carried out on-line; whilst 
functions such as to copy, list or transform the entire data bank are 
carried out as batch jobs. The variables that are used in the equations 
of an econometric model are rarely published in that form. Instead 
they are formed as functions of published variables, in some cases 
very simple ones (such as products or ratios), in other cases much 
more complex. However, these functions are programmable, so that 

the updating of a particular published variable, may in turn lead to 
the automatic updating of several other variables in the data bank 
which are specified functions of the original variable. 


ESTIMATING THE RELATIONSHIPS OF THE MODEL 





As discussed earlier, an econometric model is made up of a large number 
of economic relationships. The process of initially estimating and 
then maintaining these relationships is a continuous one, since the 
economy itself, the modellers and other economists' perception of 
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its behaviour, and the statistical tools available to the modeller 

are continuously changing, albeit slowly in most instances. Given 

the size and complexity of the national economy, most successful 
models have begun as top-down exercises, starting Simply in order to 
find out where a more detailed understanding would be most useful. 

But ultimately the models grow to a considerable size through the 
necessity to model in detail the impact of government policy variables, 
so that alternative policy strategies can be evaluated. In general, 
the modeller will begin with relatively simple relationships, and then 
incrementally introduce more detail and complexity in order to try 

to cope with its observed inadequacies; it is a classical example 

of a man-machine interactive system. 


Current economic theory will provide the modeller with initial ideas 
as to which variables might enter the relationship, but gives much 
less guidance as to the precise functional form of the relationship, 
and, in particular, to the distribution of the effects of the in- 
dependent variables over time. There are relatively few instances 
where it is believed that the effect of a change in an independent 
variable on the dependent variable in an equation is totally complete 
within the current time period. It is usually suggested that there 
will be carry-over effects over several time periods, and indeed, one 
of the major reasons for constructing econometric models is to examine 
in detail the time path of the response of the economy to changes in 
government policy variables. Thus, for example, the effects on 
consumption patterns of a change in the rate of a sales tax will not 
be seen solely in the period in which the change is made, but will be 
distributed over several subsequent time periods (hence the technical 
name of distributed lags to refer to this generic problem). Clearly, 
the significance and magnitude of these carry-over effects dependents 
on the unit time period of the data used in the mode]. Thus, if 

the relationships in the model were estimated using annual data, then 
we would expect that there would be only relatively smal] carry-over 
effects, as compared with a model estimated using monthly data. Most 
macro-econometric models of national economies are estimated using 
quarterly data. 


A-11.8 


The basic model-building process is dependent on a high degree of 
man-machine interaction, which is provided much more successfully 

on the HP 3000 than on the previous batch system. The model- 
building, estimation process is both iterative and highly suitable 

for interactive processing. It is iterative in that the modeller 
will begin with his initial relationship, which he will then refine, 
develop and evaluate by estimating many more equations, the precise 
format of each successive equation being heavily influenced by the 
results obtained from the estimation of previous equations. It is 
interactive in that interspersed with the actual estimation of the 
parameters of an equation, the modeller is likely to manipulate 

the variables in a variety of ways, and to want varying amounts of 
detail presented to him. An interactive econometric estimation 
program (ISEA, Interactive Software for Econometric Analysis) has 
been implemented on the HP 3000 to provide powerful and detailed 
Support to the modeller. ISEA interfaces with the LBS KSAM data 
banks to allow the modeller to interactively load data for analysis, 
to which a wide range of specific data transformations may be 

applied prior to the estimation process. The relationships in an 
econometric model are typically estimated using classical regression 
techniques, which the modeller can apply using ISEA, with interactive 
control over the specification of the model to be estimated (including 
specific options tailored to econometric applications, such as 
estimation subject to polynomial (Almon) distributed lags, first- 
order autoregressive error terms, linear restrictions on the 
coefficients, and so on), and over the content and volume of output 
from the estimation process presented at the terminal. Optionally, 
large volumes of output may be directed to a lineprinter. It is also 
possible to interactively estimate the parameters of a Box-Jenkins 
ARIMA time-series model using ISEA. The objective in the design 

of ISEA has been to enable the modeller as far as possible to maintain 
a continuous meaningful man-machine dialogue, in terms that the 
econometrician can readily comprehend. A brief description of the 
capabilities of ISEA is given in Appendix B. 
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MODEL SOLUTION AND SIMULATION 





As indicated earlier, in general econometric models wil] comprise a 
System of non-linear simultaneous equations, which have to be solved 
for the endogenous variables in each forecast or simulation period. 
In order to be able to solve the model in the future, values will 

be required for those variables which are purely exogenous to the 
model: (values for the predetermined variables will either be the 
appropriate historical value of the relevant endogenous variable, 

or its forecast value for a previous period). There are commonly 
two categories of variables which are likely to be purely exogenous 
to a model: those whose value is determined either directly or 
indirectly by the government, central bank, or some other economic 
regulatory agency; and those measuring the overall economic envir- 
onment, such as world output, trade, prices and so on. The major 
models for each country now tend to explicitly model those variables 
which directly influence their interaction with the economies of 
other countries (typically, domestic prices, trade prices, money 
supply, interest and exchange rates). Indeed, there is a project 

in existence (project LINK, based with Klien at the University of 
Pennsylvania, and funded by the IMF, NSF and other agencies), to 
put together on a consistent basis econometric models for individual 
countries and major regional groupings, and to solve them simultaneously 
to produce consistent forecasts of the current and capital account 
trade items, output, inflation interest and exchange rates for the 
world as a whole. This system is now operational, and the LBS model 
provides the UK model for the project. 


Prior to commencing a forecast or simulation exercise with an 
econometric model, it is standard practice to adjust it, if necessary, 
for a variety of potential disturbance factors. First, the indivi- 
dual equations are examined in order to see if the estimated values 

of the error term (the residuals) over the recent past exhibit any 
Significant systematic behaviour. Although according to statistical 
theory the expected value of the error term is zero, in practice it 

is often the case that for a variety of reasons examination of any 
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specific period will demonstrate a significant discrepancy from 
this expected value. It may well be thought that any observed 
systematic pattern will continue into the future forecast period, 
and should be explicitly allowed for. Second, even in the best 
model, there are some systematic factors whose influence is in- 
adequately accounted for by the structure of the model, but 
concerning which some reasonable ad-hoc estimate may be made for 
the future. Finally, it is often the case that the modeller has 
prior knowledge of some significant event that will occur in the 
forecast period, but which is not explicitly included in the 
model. For any or all of these reasons it is usual for the 
modeller to make adjustments to the structure of the model in 

the forecast period. This is done by making adjustments to the 
intercept or constant term of the behavioural equation determining 
the value of the endogenous variable that it is desired to adjust 
(hence they are known as constant adjustments). Values for any 
non-zero constant adjustments must then be specified before 
forecasting can commence. In practice there tends to be more 
uncertainty over the appropriate values for the constant adjust- 
ments since they are more influenced by the subjective assessment 
of the modeller. 


Given values for the exogenous variables and the constant adjust- 
ments for the forecast period, then the model may be solved for 
the values of the endogenous variables for each forecast period. 
As the model is usually a system of non-linear simultaneous equations 
it is not possible to compute an analytic solution to the model, 
and it 1S necessary to adopt an iterative numerical procedure, 
starting with an initial estimate of the solution for the forecast 
period, then hopefully converging to a solution. In general, the 
solution of systems of non-linear simultaneous equations can pose 
considerable problems in terms of successful convergance to a 
consistent solution. However, these problems do not arise in 
practice in the solution of econometric models, for two reasons. 
First, most econometric models are only mildly non-linear, with 
only a few exponential equations being the norm. Second, it is 
always the case with econometric models that we possess a good 
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initial estimate to the solution for the current period with which 
to begin the iterative sequence (at worst, we can use the solution 
for the previous time period; in practice, we often have an 
existing solution for the present period from a previous forecast 
run, with only slightly different values for exogenous variables 

or constant adjustments). Thus it is a general experience of 
econometric modellers that the computationally simple Gauss-Siedel 
algorithm will always generate a solution to such a model, normally 
in less than 20 iterations per period. 


Forecasting, or simulating alternative policy strategies, is a 
highly iterative process. The forecaster will set his initial 
estimates of the exogenous forecasts and constant adjustments , 
compute the forecast, evaluate it in some way, modify the exogenous 
forecasts and/or constant adjustments, compute another forecast, 

and so on. Because of the simultaneous nature of the models being 
used, it is normal practice to only make one or two changes each 
forecast run, so that their effect can be clearly seen (if many 
changes were made in one run it would not be possible to infer 

the effects of an individual change). To some extent this process 
is open-endedand continuous in that the adequacy or otherwise of 

a particular forecast is ultimately largely dependent upon the 
subjective assessment of the forecaster. In the context of the LBS 
model, major forecasts are published three times a year (in January, 
May and October), with short monthly ones in the intervening months. 


The actual implementation of the Gauss-Siedel algorithm for solving 
the model is as a batch job, as there is nothing to be gained from 
the forecaster's point of view in interacting with the algorithm. 
However, from forecast run to forecast run, the forecaster wishes 
to make a series of small usually incremental changes to the 
exogenous forecasts and/or constant adjustments. A set of initial 
exogenous forecasts and constant adjustments is agreed by the staff 
of the Centre as a 'control' set; the forecaster then creates an 
Editor file on-line which records his changes to the basic control 
files (which are structured as KSAM files). He then 'streams' a 
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job which solves the model, using the control exogenous forecasts 
and constant adjustments modified by the contents of his Editor 
file. The options available in the processing of the Editor file 
not only include simple one-for-one changes in value, but also more 
complex operations such as incrementing all values from a certain 
date by a constant absolute or percentage factor. The forecast 
values for the endogenous variables are placed in a KSAM file for 
future reference; in theory, the forecaster could interrogate this 
file on-line to see if it was worth printing full forecast details. 
In practice, the amount of data that most forecasters want to see 
before they are able to make such a decision is rather large, so 
the usual option is to print a standard set of national accounts 
tables on the lineprinter. A typical five year (20 period) 
forecast takes about 100 cpu seconds on the HP 3000. 


In addition to the standard forecasting and simulation operations, 
the solution system is also used for more research-orientated 
applications to determine characteristics of the system as a 
whole. Typical applications of this type would be, solution of 
the model for within-sample periods to determine the inherent error 
characteristics; computation of the dynamic multipliers for the 
major government policy variables, both singly and in combination 
(the multipliers give the proportionate change in endogenous 
variables for an appropriate unit change in one or more policy 
variables, all else being held constant); and computation of 
Stochastic rather than deterministic forecasts, in order to 
evaluate the likely error bounds for the forecast (this involves 
setting the error terms in the model to a random value drawn from 
an appropriate probability distribution). Further, a major 
exercise iS now underway to attempt to compute optimal policy 
strategies given some desired pattern of activity in the economy 
for future periods, using optimal control techniques drawn from 
control engineering. 


A-11.13 


APPENDIX A 


KSAM file structure used at LBS for time-series data-bases: 


Bytes 


1-8 

9-44 
45-46 
47-50 
91-54 
55-56 
57-62 
63-64 
65-66 
67-68 
69-70 
71-72 
73-76 
77-80 


81-800 


Description 


Variable code 

Variable title 

Frequency of measurement per year 
Start date 

End date 

Number of observations 
Variable type 

Code number 

Lag length 

Transformation number 

Ist transformation parameter 
2nd transformation parameter 
3rd transformation parameter 
Not used at present 


Up to 180 observations 
(or multiple thereof) 
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Variable type 


character*8 
character*72 
integer 
integer*4 
integer*4 
integer 
character*6 
integer 
integer 
integer 
integer 
integer 
real 


real 
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ISEA commands (version 6.4, 2 October 1978): 


AUTO 
BOXu: 


CORR: 
DATA: 


DIM: 


EDIT: 


Computes autocorrelation coefficients 

Computes the parameters of a seasonal Box-Jenkins ARIMA 
model: 

Output options: 


AUTO: autocorrelation coefficients of residuals 
PAUT: partial autocorrelation coefficients of residuals 
PRES: print actual, fitted, residuals and percent error 


SRES: save, in the ISEA data matrix, the fitted, ratio 
of actual/fitted, or the fitted + and - one or 
two standard errors 


GRAF : plots residuals or actual and fitted at terminal 
VCOV: variance-covariance matrix of estimated 
coefficients 
BCOR: correlation matrix of the estimated coefficients 
FORE : compute a forecast, and (optionally) save in 
the ISEA data matrix 
MODL: prints standard output on the lineprinter 


Computes simple correlation coefficients 
Enters data into the ISEA data matrix, 


LE. from the terminal 

K: from an LBS KSAM file 

Fs from a file ‘kept’ by ISEA 
Es from an Editor file 


Re-dimensions the ISEA data matrix (the default is 300 
observations on 20 variables; this may be increased to 
500 observations and 50 variables, so long as the product 
of the two does not exceed 8000). 

Edits the data in the ISEA data-matrix: 

ACOL: adds a column 


CCOL: changes a column 

AROW: adds a row 

CROW: changes a row 

COBS: changes an observation 


AFOR: adds date from a CEF KSAM forecast file 
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GRAF: 


KEEP: 
LPNT: 
ME AN : 
MISS: 
NAME : 


PAUT: 
PLOT: 
PRNT: 


REG: 


Plots a variable at the terminal, either across or down 

the page. 

Keeps the ISEA data matrix in a private sequential file 

Prints the contents of the ISEA data matrix on the lineprinter 
Computes means and standard deviations of variables 

Specifies a value to indicate missing observations 


Prints the names of the variables currently in the ISEA 


data matrix 
Computes the partial-autocorrelation coefficients 
Plots up to three series on an HP 7203 graph-plotter 


Prints the contents of the ISEA data matrix 
Specifies a regression equation (default is OLS), options: 


OLS: Ordinary Least Squares 

TSLS: Two-stage Least Squares 

RSLS: OLS subject to linear restrictions 
ALMN : Almon distributed lags 

AUTO: Include Ist order-autoregressive term 
NCON: Supress constant term 

LOG: Print true statistics for a log equation 
WGHT: Weighted least squares 

DSCT: Discounted least squares 

STRT: Start date for sub-sample 

END: End date for sub-sample 


Output options: 


AUTO: autocorrelation coefficients of residuals 
PAUT: partial autocorrelation coefficients of residuals 
PRES: print actual, fitted, residuals and percent error 
SRES: Save, in the ISEA data matrix, the fitted, ratio 
of actual/fitted, or the fitted + and - one or 
two standard errors 
GRAF: plots residuals or actual and fitted at terminal 
VCOV: variance-covariance matrix of estimated 
coefficients 
BCOR; correlation matrix of the estimated coefficients 
FORE: compute a forecast, and (optionally) save in 
the ISEA data matrix 
MODL: prints standard output on the lineprinter 
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SMTH: 
TRAN: 


Exponential smoothing (Winters method) 
Compute any of the following transformations: 


LAG: 
LOG: 


DIFF: 
MSUM: 
MAVE: 


ADD: 


SUBT: 
MULT: 
DIVI: 
RECP: 
POWR: 


EXP: 


CSUM: 
TIME: 
MULC; 
ADDC: 
SUBC; 


ABS: 


SUMV: 


EXS: 
DEV: 


DUMY : 
SDUM: 


lag the observations on a variable 
natural logs 

differencing 

moving sum 

moving average 

Sum two variables 

subtract one variable from another 
multiply two variables 

divide one variable by another 
reciprocal of a variable 

raise to a power 

e to the power of a variable 
cumulative sum 

time trend 

multiply by a constant 

add a constant 

subtract from a constant 

absolute value 

sum several variables 

Simple exponential smoothing 
positive, negative (or both) deviations from 
zero, mean or a specified value 
form a dummy variable 

form seasonal dummy variables 
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CWF/3000: A COMPLETE SYSTEM FOR COMPUTER 
ASSISTED INSTRUCTION AND TRAINING 


HAROLD J. PETERS 
EDUCATIONAL SOFTWARE PRODUCTS 
9 GEORGETOWN CIRCLE 

IOWA CITY, IOWA 


What is CW? 

CW stands for "“coursewriter", which is an authoring language 
for computer-assisted instruction (CAI). Figure 1 shows a sample 
of student interaction with a CAI lesson that was written with CW. 
While the subject matter can of course vary greatly, this example 
is typical of the sort of tutorial dialogue that can readily be 


written with the CW language. 


Figure 2 shows the CW code corresponding to the sample student 
interaction in Figure 1. The two letter "op-codes" are almost self- 
explanatory; QU: question, CA: correct answer, TY: type, WA: wrong 
answer, UN: reply for unexpected answer. This example illustrates 
the principal advantage that CW, or any other CAI authoring language, 
offers over a general purpose programming language -- that is: implicit 
branching. If the student's answer does not match the argument of the 
CA, then processing automatically branches around the TY associated 


with the CA and on to the next implied comparison, the first WA. 
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FIGURE 1 


Most nouns ending in "ch" form plurals 
by adding "es". 
For example, 
"church" becomes “churches", 
"lunch" becomes "lunches", etc. 
What is the plural of "torch"? 
torchs 
"torch" ends in "ch". Please try again. 
terches 
I think you've spelled "torch" wrong. 
torches 


Good! Try another. 


Figure 1. A sample of student interaction with a CAI course 


written in CW. 
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QU 


CA 
TY 
WA 
TY 
WA(L) 
TY 


UN 


BR 


Figure 2. 


FIGURE 2 


Most nouns ending in "ch" form plurals 
by adding "es". 
For example, 
"church" becomes "churches", 
"lunch" becomes "lunches", etc. 
What is the plural of "torch"? 
torches 
Good! Try another. 
torchs 
No, “torch ends in "ch". Try again. 
t&ches 
I think you've spelled "torch" wrong. 
Please try again. 
No. The answer is "torches". The ending “es” 
is added for the plural because "torch" ends 
in "ch". Try another one. 


PR 


CW code for the sample student interaction given in 


Figure l. 
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Again, if there is no match a branch is made automatically to the 
next implied comparison, etc. If on the other hand, the student's 
answer does match the argument at one of the implied comparisons, 
then the corresponding TY (and/or other so-called "minor" op-codes) 
is executed and all further comparisons are skipped over in an 


automatic branch to the next question. 


All this implicit branching does save a lot of busy work on the 
part of the author and lets him concentrate on the higher-level 
structure of the lesson. It clearly does not absolve the author 


of all programming tasks but it does make his job a lot less tedious. 


First appearing in the early 1960's, CW has to be considered 

one of the authentic pioneering languages for CAI. Many CAI 
languages have come along since the introduction of the first version 
of CW. And this leads to legitimate speculation as to why this "old" 

language stil] manages to survive. Two reasons appear most prominent. 
First, CW is extensible: the short-comings in its original design 
can be circumvented by the use of its user-written function feature. 
Any programming function within the capabilities of the underlying 
software system can in principle be invoked by a CW course through 
use of the user-written function feature. Within a CW course, the 
function call is simply | 

FN MYPROG 

where MYPROG is the name of the user-written function to be invoked. 


More will be said regarding user-written functions in a later section. 
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The second factor contributing to the longevity of CW is that because 
of its early existence on the most popular equipment, i.e., IBM, 

a great deal of courseware has been created in CW over the years, 

and the easiest way for newcomers to CAI to get off to a running 
start has been to tap into that large reservoir of courseware by 
getting a CW system themselves. They then in turn create more 
courseware and so the bandwagon goes on. It was precisely this 
second attractive feature of CW -- the large accumulated base of 
courseware -- that originally drew the interest. of Hewlett Packard -- 


and leads to the next question: 


What is CWF? 

CWF stands for Course Writing Facility, Hewlett Packard's name 
for its emulation in BASIC of IBM's CWIII (the version of CW current 
in the early 1970's). CWF was originally developed for the HP2000 
timesharing system, and some 15-20 CWF systems were sold prior to 
HP's withdrawing it from the market, at least partly in anticipation 
of the obsolescence of the HP2000 itself. Essentially all features 
of CWF in its HP2000 implementation have been retained in the 
HP3000 version, so the description of those features is deferred 


to the next section. 


What is CWF/3000? 

Building upon its HP2000 predecessor, CWF/3000 provides on the 
HP3000 essentially all the course authoring, course presentation, 
and student-keeping capabilities of IBM's Coursewriter III, version 
3 (CWIII), plus a significant additional feature not offered by 


CWIITT. In CWIII, the extensibility described earlier is achieved 
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through user-written functions programmed in IBM that such functions 


can be written directly in BASIC. 


CWF/3000 consists of four major subsystems: course authoring, 
course translation, student usage, and record keeping/reporting, 
each described in turn below. 

Course Authoring 

CWF/3000 authors use a set of programs headed by CWEDIT to enter, 
revise and edit new course material, using the CW language op-codes 
such as shown earlier in Figure 2. Some thirty op-codes, many of 
which may. be modified in several ways, offer wide flexibility to 
the author. For example, the CA op-code in simplest form accepts 
exactly one correct answer: 

CA torches 

With an "L" modifier, a variety of answers can be accepted through 
usage of "don't care" characters. For example, 

CA(L) t&ches 
will accept "torches", "touches" or "txyzches" or any other 
"word" beginning with’ "t" and ending with "ches", as correct. 
Another modifier,"W", allows more specific alternative correct 
answers. For example, 

CA(W) torches lamps candles 
accepts these three and only these three as alternative correct 
answers. And if all this flexibility is not enough, the author can 
resort to a user written function, e.g., 
FN ANSWER 


and rely on his own BASIC program, ANSWER, to achieve any type 
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of answer processing he may desire that can be implemented within 
the broad generality of BASIC. The experienced CWF/3000 author 
moves flexibly between CW and BASIC, taking advantage of the 
best features of each as the occasion demands. Very roughly, CW 
is superior in dialog-intensive work such as in tutorials, and 
BASIC is superior in computation-intensive tasks such as simulations. 
Course Translation 

In principle, any CWIII course developed on IBM equipment can be 
converted via CWF/3000 conversion programs to CWF/3000 compatible 
form and then used, revised and edited just like any other CWF/3000 
course. In practice, virtually every conversion we have seen 
attempted has succeeded -- eventually. The biggest problem -- when 
there have been problems -- arises with courses that make extensive 
use of special display characteristics. The special display 
features available on the system on which the course was originally 
offered may not be available on the target system. And even if they 
are, they are likely to be implemented differently so that con- 
siderable conversion attention may be necessary. But whatever effort 
may be required, it is almost invariably true that starting with 
someone else's courseware and modifying it in whatever ways necessary 
to meet one's own needs remains a far superior method for getting 
usable courseware up and running than by starting from scratch on 
one's own. So it remains the case that the principal source of 
attraction in CWF/3000, as in its predecessors, is the ability it 


gives the user to most easily tap into a large existing base of CW 
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courseware. The 1978 Index to Computer-Based Learning! lists 311 
instructional modules developed in CWIII that in principle should 
be readily convertible to CWF/3000. In addition, the Index lists 
720 modules written in BASIC, which are compatible with CWF/3000 
in important ways, as described in a later section. 
Student Usage 

CWF/3000 incorporates HP's Instructional Management Facility, 
IMF, to handle student sign-on, sign-off and some of the student 
record keeping. Hence a student taking a CWF/3000 course enters 
through the IMF program START in the following standard fashion: 

RUN START .PUB 


What is your ID number and first name? 1000,Jimmy 
Is your last name Carter? Yes 
Course name? ENG4 


30 September 1978 14:49 Port 7 


Welcome, Jimmy to session number 3 of English 4. 
In our last session.... 
Whenever the student signs off by typing //STOP or //SIGN OFF, or 
is signed off automatically by the instructional program, the 
CWF/3000 system saves his restart information so that he may 
begin his next session where he left off in the last one, or 
wherever else the author may wish to designate. 


Record-Keeping/Reporting 


In addition to student restart information, as already described, 
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many other types of information relating to student usage of a 
CW course can be recorded and later reported. Information con- 
cerning essentially any aspect of student interaction with the 
course material can be saved by one means or another. 

Perhaps most common is simply keeping track of correct answers 
in a session, reporting this to the student at sign-off time, and 
possibly recording the number for reporting to the instructor later, 
or maintaining a cumulative day-to-day record of scores for benefit 
of both the instructor and student. Another common type of information 
saved is the number of times each registered student has accessed a 
course and how much cumulative time the student has spent on the 
course. 

During the development phase of a course it is especially im- 
portant to accumulate all unanticipated student answers, i.e., all 
answers for which no tailored replies had been prepared and for 
which only the "reply to unanticipated answer" (the argument of 
the UN op-code) is displayed to the student. Frequently, these 
unanticipated student answers will suggest that parts of the course 
need further development work, including perhaps new explanatory 
passages, or at least a broader array of model answers and 
corresponding tailored replies. Most of the record keeping and 
reporting functions that have been mentioned require that students 
be registered for courses, and that the courses themselves first 
be entered into the IMF record keeping system. Some examples of 
instructor or proctor interaction with the IMF programs are shown 


in Figure 3. 
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FIGURE 3 


A. Entering a course 
RUN ADMIN .PUB 
CODE?MMMMMM 
COMMAND?COURSE 
COURSE COMMAND?ENTER 
COURSE NAME?REX 
CODE WORD?R1 
DOES IT HAVE A DEMO MODE?YES 
SPECIAL COURSE TYPE?CW 
REX IS NOW ENTERED AS A COURSE. 
COURSE NAME?//STOP. 
DONE 
B. Enrolling a student 
RUN PUPIL .PUB 
CODE?MMMMMM_ 
COMMAND?ENTER 
FIRST NAME?JOE 
LAST NAME?SWARTZ 
ENTERED WITH ID NUMBER 1018. 
COURSE NAME?REX 
GROUP NAME?MS NOEL 
HISTORY FILE OF REX INITIALIZED TO 9 STUDENTS. 
AREA NUMBER?1 
USER GROUP NUMBER?1 
ENROLLMENT COMPLETED. 
FIRST NAME?//STOP 
DONE 


Figure 3. Some examples of instructor or proctor interaction with 


IMF record keeping programs under CWF/3000. 
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As a final note regarding recording keeping, we should point out 
that the CWF/3000 record keeping facilities are available for BASIC 
language courses as well as CW courses. It is typically the case 
that computer-based instructional materials written in BASIC have 
not used any kind of student record keeping functions. Typically 
instructors have no information as to which students have used the 
modules nor as to how well they have performed. It is certainly 
difficult to assess the instructional value of CAI materials in 
this case. And refinement of the modules, or development of new 
materials must be based on guesswork rather than hard data. Once 
again, the record keeping and report facilities of CWF/3000 provide 
a ready solution to these problems for both BASIC and CW courses. 
Some Technical Considerations 

CWF/3000 has not been optimized for the HP3000. As of September, 
1978, only the student driver programs have been compiled so that 
they can run as object code rather than under the BASIC interpreter. 
This provides good performance for up to 15-20 students running 
most CW materials. 

Some technical problems have delayed compilation of the 
authoring programs, which means that some authoring functions 
execute much more slowly than desired. 

Beyond simple compilation of the various programs com- 
prising CWF/3000, it is clear that substantial further optimi- 
zation could be achieved through redesign of the file structures, 


which still suffer from design constraints imposed by the early 
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HP2000 series time sharing systems. These and other refinements 
to CWF/3000 await the indication of further interest in the 
system by HP3000 users. 
Availability 

CWF/3000 has been developed by and is available from (under a 
license agreement) Educational Software Products. Requests for 
further information should be directed to the author, at that 


organization. 
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STATISTICAL INQUIRY & RETRIEVAL 
an IMAGE application 


MARTIN D. JEWEL 
NATIONAL SPINAL CORD INJURY DATA RESEARCH CENTER 


BACKGROUND 


The National Spinal Cord Injury Data Research Center 
CNSCIDRC) - a division of Good Samaritan Hospital in 
Phoenix, Arizona - is supported in part by a grant fron the 
U.S. Department of Health. Education & Welfare through the 
Rehabilitation Services Adninistration. NSCIDRC’s goal is 
to provide access to a national repository of data relative 
to spinal cord injured persons for the purpose of improving 
the care and treatnent thereof. and reducing the length of 
hospital stay and associated costs. 


Since spinal cord injury is a sudden traumatic shock and 
extrenely expensive, the costs are often borne by society in 
the form of taxes and insurance premiums. Helping a patient 
to achieve his nost productive status as quickly as possible 
gives him a psychological boost. reduces the drain on fanily 
and personal resources, and decreases the cost to society. 


SYSTEM FLOW 


The source of patient data is the eleven Regional Model SCI 
Systens (see appendix 1). Data is extracted from hospital 
records, physicians’ statements, patient interviews and 
bills for various types of equipment and services. This 
information is compiled by medical record personnel and 
transcribed onto pre-printed foras. The forms are assenbled 
into batches upon completion, logged. and then forvarded to 
Phoenix. Generally. a batch represents a weeks vork. (see 
Figure 1). 


After receiving the batched forms at NSCIDRC. the forms are 
logged in on the HP360060 and sorted by new entries and 
updates (see Figure 2). The new entry data is keyed into 
the computer via an HP2645 video terminal using a general 
purpose data entry progran designed to create ao transaction 
file. We do not use DEL. having found it inadequate for our 
needs. 
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Processing at the Regional SCI Center 


Data 


Collection 


Batch finished 


forms and log 


Mail to 
NSCIDRC 





Figure l. 
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Processing at NSCIDRC 


Receive batch, 


Date stamp 


each form 







Log each 
form into 


computer 


Sort 
entries 
from updates 


Updates 


Figure 2. 


A-13.3 


At appropriate periods, usually twice a day» a data base 
posting program is executed as a batch job strean to add the 
data to the data base (see Figure 3>. We do not enter data 
directly to the data base. 


Twice monthly, a data quality audit program is run to 
produce a discrepancy list which is forwarded to the 
Regional SCI Centers for corrective measures. Resultant 
updates are then sent to NSCIDRC as described above. The 
updates are posted to the data base on-line. Data 
verification is done after entryu/posting and updating. 


Other data base managenent tools are shown in Figure 4. The 
selective dump provides a hardcopy of patient data as if 
exists in the data base. The Foran 2 Follow-up produces a 
tickler report of those forns which are due during the next 
quarter, and an expediting list of in-process and past-due 
forns. 


We have grown increasingly confident of the relative 
cleanliness of the data base. We now average fever than 2 
discrepancies per 190 foras. With the many checks for 
validity and logical interrelationships between variables, 
the error rate is approximately i in 40,000. 


DATA FLOW TIRING 


Patient information cones to NSCIDRC at the completion of 
the initial hospitalization and rehabilitation period, and 
again at each subsequent anniversary of injury. There may 
be a lag time of up to three nonths while data is extracted 
from case records and various professionals respond to 
requests for information. Typically. after three to six 
months after the end of a calendar year the data for that 
year is complete. clean and ready to be analyzed. 


The form, on which the initial data is submitted, is 
referred to as Form 1 and is complete in itself. The annual 
follow-up data is reported ona Fora 2. Each Form 2 may 
have one or more Hospitalization forns (Form H> attached. if 
the patient was adnitted to a hospital during that year. 
Thus, a particular patient will have a single Form 1. and, 
depending on the number of years after injury, one or nore 
Forn 2’s. Each Form 2 may, in turn, have one or more Forn 
H’s attached. 


DATA BASE MANAGENENT BACKGROUND 


Initially, data vas stored on an IBM Systen/32 which had 
many hardware and software tinitations. It was linited to 
producing RPG reports and had no data base capabilities. In 
addition, the volume of data was not sufficient for 
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Figure 3. 
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analysis. As a result. there were no useful precedents for 
statistical inquiry and analusis. 


With the growth in data volume: as well as the desire to 
perform statistical analyses and to make the data available 
for analysis via remote terminal, a hardyare and software 
evaluation was conducted of available systems in the 
$106-150K price range. The HP3000 was selected as the best 
systen in that price range. Selection was based on ease of 
use, multi-lingual capabilities, and data base manaqenent 
software in a time-shared and batch oriented systen. 
NSCIDRC’s data processing facilities are outlined in 
Appendix 2. 


We elected to use IMAGE and. at least initially, QUERY. For 
our beginning efforts at inquiry into the data base and to 
check our conversion, QUERY was. to say the least, very 
handy to have. However, in establishing NSCIDRC’s data 
bases under the HP-3000 IMAGE data management facility, it 
was obvious that the HP QUERY progran, although a good 
general approach to on-line inquiry, was not adequate for 
our needs. As a result. NSCIDRC Computer Services undertook 
to design and implement a full function program that would 
serve all of our data bases and provide efficient 
interactive access to the data with our special needs for 
security, ease of use, and statistical analusis in mind. 
INQUIRY is the result of that effort. 


In order to better conprehend NSCIDRC’s data base nanagenent 
needs, let’s examine the data base structure. 


DATA BASE ORGANIZATION 


NSCIDRC’s data base structure was designed to anticipate the 
need for a variety of possible access andes. The present 
schema structure is outlined in Figures 5 & 6. Because the 
schema was designed to allow use of QUERY, certain 
inefficiencies Cwhich may be obvious to the experienced 
HPSO00 user) were introduced. We will address these aspects 
at a later point. 


We utilized Automatic Masters because we anticipated access 
to the data base from a variety of directions: patient 
number, center, number of hospitalizations, anniversary 
year, etc. We have learned from experience that the only 
Masters we need are File-key (center, patient number and 
anniversary year. conbined) and Center. The reason for this 
is that data is generally selected on the basis of a 
combination of logical selection criteria applied to several 
different variables or data itens. 
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Data Base Structure 
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Figure 5. 
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Figure 6. 


At NSCIDRC., the data bases are accessed in one of the 
following ways! 

* Serial, by primary dataset 

* Chained read. by Center 

* Caiculated read, by File-key. 
INQUIRY utilizes the three methods above, plus directed read. 


RETRIEVAL REQUIREMENTS VERSUS QUERY 


A brief look at the features of HP’s QUERY progranm is 
appropriate here. These features are as follows: 


* Interactive English-language commands. like FIND 
and LIST 


* Single data set access 


* Command features such as! 

- Find command accesses any single dato set for 
selection of data by logical coaparisons 

- List command, with access similar to Find, 
produces columnar listings of desired 
variables; some colunn headings will be 
truncated 

- Report command allows flexible output report 
formats, including sorted details, colunn 
totals, and register manipulation (calculate 
averages, etc.> 

- Report commands nay be repeated to display 
other variables Cout List may not> 


* Update command features: 
- Pirect access to a particular variable by nane 
- Add. replace or delete a data record 
- Global replacement of a specific variable 


* Execute from a conmand fite 


* Execute pre-written procedures for data selection, 
reports, etc. 


While we liked QUERY’s English-like comnand-driven style. we 
required multiple-dataset access. We wanted to be able to 
relate the entry foras and variables to the datasets so that 
the user need not be concerned with data base structure. 


Ye wanted a List command that did sone simple, automatic 
formatting, without losing vital header information. Since 
ve were interested in statistical inquiry, we wanted 
elenentary statistics on all listed numeric fields. 

Further. we wanted to be able to save a selected population 
and to extract from the data base as a separate file desired 
variables based on the subset population. 
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While QUERY must create an internal “tag" file of pointers 
to selected data, it is prebably in an extra data segment. 
In any case, it cannot be saved, nor is it accessible to the 
user. 


In addition, QUERY provides no simple means of creating an 
output disk file of selected variables fron the subset 
population. The listing file can be equated, but that is a 
messy and undesirable workaround. particularly for the 
unsophisticated user. 


DESIGN OF THE INQUIRY PROGRAN 


The following outline summarizes the features of the INQUIRY 
progran:! 


* Multiple data set access 


* EDITable directory file contains indices to relate 
data sets, forms. and groups of variables}? output 
formats for the List function: field type and 
position for the Find function 


* Selection of variables by number as on the data 
entry forms 


* Command features such as: 

- Find command accesses all data sets in the 
specified forn 

- Find can pseudo-chain across form boundaries, 
that is, it can access both Form 2 and its 
corresponding Forn 1. 

- Find can locate cases of multiple occurrences 
of a value (e.g. those patients with 2 spinal 
fusion operations) 

- Find allows use of parenthetic notation: 

F NATL1 ¥104 < #7 AND & 
C¥120=5" 030" OCC 2 OR V1I3ZO=" O30" OLE 2) 

- Temporary Tag files created by the Find cornnand 
define the population and may be saved and 
later recalled as required: both positive and 
optional negative tagfiles can be created 

- List conmand, with access similar to Find. 
produces neat columnar listings of desired 
variables; for numeric variables, produces 
elementary statistics at the end of the list; 
details may optionally be sorted, or 
suppressed: variables may be decoded thru 
automatic tabular look-up for more readable 
Listings 

- List and Output File commands moy be repeated 
to display other variables fron the sane 
population, and subsets fron the population may 
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be Listed or Output to a File via the IF option 
which alloys further selection fron the 
"tagged" population 

~ Output File may contain up to 20 variables and 
is conpatible with the input requirements of 
SPSS and LISA, statistical packages available 
on the systen 

- Frequency command produces a table of 
frequencies, cumulative frequencies. and cell 
counts, along with statistical totals. 

- Transform function allows creation of a 
pseudo-variable for use in List. Frequency, and 
Output File conmnands. 


* Execute fron a conmand fite 
* Conmand termination on Control-yY 


The relating of datasets, forms and variables was solved by 
the use of a driver directory file. All access to the data 
bases uses the directory file indices which are 
core-resident, except for the variable descriptors’ portion 
which, because of its size, is accessed by a binary-search 
routine. 


The use of a private directory file as a driver has many 
important implications. The data base may utilize 
Single-byte fields, odd-length fields. mnultiple-occurring 
fields. Fietds may be redefined. Thus a date may be 
accessed in its entirety as YYMMDD. or just the year as YY, 
while occupying only 6 bytes of space. The only Limitation 
on redefinition is that search-keys must be uniquely 
defined, although even they nay be redefined for purposes of 
data manipulation within the program. The directory file is 
not a privileged file and is quite separate from the data 
base. Therefore, it may be edited and modified as required 
without necessarily affecting the data base or its schenoa. 


Because INQUIRY is designed for use by relatively 
unsophisticated users who are familiar with the forms and 
the patient data - but not data bases or prograns - it 
assumes a set of operational defaults. These defaults may 
be over-ridden by a simple command. Anong the defaulted 
options are: choice of single- or double-spaced listings, 
"noisy" or “quiet" mode Cin which various messages are 
Suppressed for the experienced user), and a tookup feature 
in which coded data is decoded for more readable listings 
Ce.g. sex code of 2 becomes "Fenale*). 


All commands are accepted in both full English as well as 
shorthand, e.g. “FINO" or simply "°F". Simple error messages 
and help nessages are provided. Syntax is entirely 
free-form, with continuation lines and multiple commands on 
a single line allowed. 
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A CLOSER LOOK AT THE INQUIRY PROGRAK 


INQUIRY is written in nodular fashion in COBOL. While not 
strictly structured. it is functionally top-down in design. 
Although a large progran, it has been carefully designed to 
hinimnize swapping and maximize execution efficiency. Its 
stack size of 30090 is necessary primarily because of an 
integral sort statement. Progran segments responsible for 
the data base I70 are self-contained so that no segnent 
transfer takes place until it has completed its task. As an 
example, the Find command is set up in one segment and 
executed in a second segment which retains complete control 
until that command is finished. 


Data base I[/70 transfers are performed in “all-itens" Ci.e. 
full record) node. The extraction of bytes is performed 
entirely by the prograna rather than by IMAGE intrinsics. 
This is the key to the odd-length field access, and the 
ability to handle nultiple occurrences. 


USING INQUIRY IN THE ANALYTICAL PROCESS 


In practice, INQUIRY can be used to peruse the data base or 
to extract a data matrix to test a tentative hypothesis. 

The user will usually save his tag file which contains 
binary record pointers to the population selected. These 
pointers are used to perform directed reads in IMAGE. If 
the user should decide to extract a second group of data 
items, the tag file previously created provides rapid access 
to the sane population. Figure 7 outlines the basic inquiry 
and analysis flow. 


INQUIRY can be used interactively, although it is often nore 
appropriate to create a Strean file for batch execution and 
return later for the results. This is because the tine 
between responses to user commands may range fron a few 
seconds to several minutes, depending upon the access node, 
number of datasets and records accessed, and the overall 
System toad at the tine. 


A sample Job stream with annotations is shown in Figure 8. 
R sample listing and frequency table are shown in Figures 9 
and 10, 


Our user base is spread over the United States and thus 
connect time and telephone charges can be expensive for sone 
users. We have established alternate methods for the user 
with tocal analytical capabilities. The user can run 
INQUIRY and create a data matrix of selected variables fron 
a tagged population. He may then elect to use SPSS or LISA 
on the NSCIDRC HP3000. 
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{JOB MARTY JEWEL/PASS 

'RUN INQUIRY .MARTY . JEWEL 

B NATL; M A Ti M QUI;OL 
specify which data base; access 
all data; create a tag file; 
use “quiet” mode; output to the 
line printer 

F NATLi ¥103=1 AND ¥132D<5 (€¥119=7070 OR ¥129=7070> 
in Form 1. select patients meeting 
certain criteria 

FR ¥i0? 1353S SORETAG 
create a frequency table of variable 
¥i9O/7 Caged in 1S-yeer groups; 
save the tag file as SORETAG 

¥ COST??? 
recall a previously saved tag file 

TRAN ¥1614¥166T 
establish an equation for a 
pseudo-variable (transformation? 

LT Viel ¥166T TRAN 
List totals only for the variables 
Shown, including the pseudo- 
variable, TRAN 

TRAN Vi6O04+¥1644+V169T4V170T 

LT ¥160 ¥164 ¥169T ¥V170T TRAN YVi72 

OF CSTHATRKX V¥161 ¥V162 V163 V1iG6GT V1IE7T & 

¥168T TRAN V1/72 ¥1is2b ¥1I62 
create an Output File called 
CSTMATRK containing 10 variables 
as columns, each patient being 
represented as a row; from the 
population given by tag file 
COST?7; “"&" means continuation 


'EOUJ 


Figure 8. 


If the user has a terminal with a local storage capability 
Ci.e@. tape cartridge, diskette, etc.>, the user can sinmpty 
use FCOPY to transfer the data matrix to his terninal 
storage medium. Then the user can dial his local computing 
facility and feed in the data for statistical analysis. 


For the user whose tine constraints are more flexible, or 
who requires a large quantity of data, the data matrix Cor 
the entire Regional Center data> can be dumped to a magnetic 
tape and mailed to the Center. 
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SELECTED CASES 
AS AN EXAHPLE 


i326 108 199 i3l 
NEUR IHPAIR SEA RACE DAYS INJURY 
DISCH 
Para Compl Female Caucasian 96 
Para Compl Female Latin Amer. 1ii 
Para Compl Wale Aner. Indian 112 
Para Compl Male Caucasian 38 
Para Compl fale Caucasian 69 
Para Conpl Hate Caucasian 97 
Para Compl Hale Caucasian 99 
Para Conpl fale Caucasian 157 
Para Conpl Male Caucasian 167 
Para Conpl Male Latin Aner. 126 
Para Incosap Female Caucasian 90 
Para Inconp Female Caucasian 135 
Para Inconp Hale Caucasian 111 
Para Incomp Male Latin Amer. i32 
Quad Compl Female Amer. Indian 15% 
Quad Compl Fenrale Amer. Indian 216 
Quad Compl! Male Amer. Indian 132 
Quad Compl fale Caucasian 134 
Quad Conpl Male Caucasian 176 
Quad Compl Male Caucasian 1793 
Quad Compt fale Caucasian 189 
Quad Compl fale Caucasian 238 
Quad Incomp Female Caucasian 127 
Guad Incomp Male Amer. Indian 133 
READ = 
192 
SELECTED: 
24 
SUHS: 
3257 
HINIMUA: 
38 
HAXIMUR: 
238 
RANGE: 
186 
MEAN: 
135.706 
STD DEV: 
| 43.89 
SUH OF SQUARES: 
486305 


Figure 9. 
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AGE AT INJURY 
IN 15-YEAR GROUPS 


107 
AGE 


COUNT = 
31 


CELL VALUE FREQUENCY CUM. FREQ 


o TO 14 16.13 16 
i5 TO 29 41.94 38 
30 TO 44 12.96 79 
45 TO 39 12.96 $3 
60 TO 74 12. 90 96 
75 TO 89 3.23 1096 
SUMS: 
973 
MINIMUM: 
3 
MAXIMUM: 
75 
RANGE! 
79 
MEAN : 
31.38 
STD DEY: 
19.57 
SUM OF SQUARES: 
42031 .90 
MODE: 
iS TO 29 
HEDIAN: 
26 
Figure 10. 
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CELL COUNT 
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THE FUTURE OF THE DATA BASE 


In the near future, we plan to reorganize the data base in 
order to eliminate the undesirable space-wasting aspects 
mentioned earlier. We estimate that the reorganization, 
while Losing Some compatibility with QUERY, witt save 
approximatety 13% of the disk space currently used. In 
addition, eliminating the Common dataset wilt reduce the 
number of accesses by 25 to 50 percent, depending upon the 
variables accessed. 


The reorganization will take into account: 

* Odd-length fields 
Hultiple-occurring fields 
Redefinition of fields, ineluding search keys 
Elimination of the Conmon dataset by 
expansion of the Form 1 and Fora 2 datasets 


*% 2 & 


Just how do we plan to iaplenent the reorganization? A 
conversion program vill write consolidated records to a 
tape, elininating the Common dataset and the unnecessary 
bytes in various fields. Then we will purge the old data 
base. create the new root file and data base allocation. UWe 
will then sort the tape by file-key and utilize another 
special program to load the data base from the sorted tape. 


Since we are also nodifying the data base syllabus 
Cdefinitions) and adding some new variables, the conversion 
program will have to translate some data to new values. 
This will result in a semewhoat more conplex program, but 
will allow us te do the job in a single pass. 


The structure of the planned data base is shown in Figures 
li and 12 (compare with Figures 5 and 63. 


SUMMARY 


Spinal cord injured patient data fron eleven Regional SCI 
Centers is submitted to the National Spinal Cord Injury Data 
Research Center in Phoenix, Arizona. The data is entered 
into an IMAGE data base on NSCIORE’s Hewlett-Packard 3000 
using custom-designed software. The use of custom software 
for inquiry and retrieval was necessary in order to access 
multiple datasets at one time. It was also needed to relate 
entry forms and variables to the data base structure for 
user ease and convenience. 


The INGUIRY progranm provides elementary statistics as well 
as the ability to save o subset population for later recall. 
It may also be used to create an data matrix as an output 
file for further analysis. — 
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An added advantage of the INQUIRY program is the space 
Savings which result from freedon from the usual lLinitations 
of the HP BUERY/3900 progran. 
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Planned Data Base Structure 
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Figure ll. 


Hospital 
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THE NATIONAL DATA BASE 


— 


Figure 12. 


Appendix 1 


The National Spinal Cord Injury Model Systems’ Project is 
sponsored in part by the Rehabilitation Services 
Administration, Department of health, Education and Welfare. 
The following are participating institutions: 


University of Alabana? Birninghanm, AL 


Good Samaritan Hospital - St. Joseph’s Hospital: 
Phoenix, AZ 


Santa Clara VYalley Medical Center; San Jose, CA 
Craig Hospital: Denver. CO 


Northwestern Menorial Hospital - Rehabilitation 
Institute of Chicage;: Chicago, IL 


Boston University Medical Center; Boston. MA 
University of Minnesota Hospital: Minneapolis, HN 


Institute of Rehabilitation Medicine, New York 
University; New York. NY 


Texas Institute for Rehabilitation and Research, 
Baylor University? Houston, TK 


Yoodrow Wilson Rehabilitation Center; Fishersvitte,. YA 
University of Virginia: Charlottesvitle. VA 


University of Bashington; Seattle, WA 
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Appendix 2 


NSCIDRC 


The National Spinal Cord Injury Data Center 


Data Processing Facilities 


50 MB 
Disk 
Console 
HP-3000 
Series II 50 MB 
Model 5 Disk 


256 Kbytes 





User Terminals 
(up to 15) 


800 BPI Printer 
Magnetic 





Tape 


Software support: 


Languages: COBOL, FORTRAN, BASIC, SPL (extended ALGOL) 


Data Base Facilities: IMAGE (data management system) 
QUERY (inquiry and reporting) 


Libraries: DEL (Data Entry Library) 


Scientific Library 
Operating System: MPE III (Multi-Processing 
Executive IIT) 
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ON-LINE MARKETING INFORMATION 
GEORGE J. NEIBERGS 
E.S.B. EXIDE INDUSTRIAL BATTERIES 


BACKGROUND 


Exide Industrial Battery is a division of ESB Ray-0-Vac which is a 
wholly owned subsidiary of INCO Corporation of Canada. ESB was founded 
in 1888 to supply batteries to Philadelphia Electric. The Industrial 
Battery Division has its headquarters in Horsham, Pa., just outside 
Philadelphia, and manufacturing plants located in Sumter, S.C., 
Richmond, KY. and Raleigh, N.C.. 


The primary products we manufacture include industrial batteries 
for lift trucks and uninterrupted power supplies with batteries for large 
computer installations and process control industry where backup power is 
required. In Raleigh, we manufacture the chargers for batteries and 
uninterrupted power supplies. The products are sold by our own sales 
force from 18 locations in the U.S. There are 34 Service Centers where 
the field inventory is kept. 


In the past five years, there have been major changes in this 
Division. New products have been introduced and an old plant was closed 
in Philadelphia. Essentially, the Division has been undergoing change 
and revitalization. 


One of the areas identified as requiring substantial change was in 
the development of new operations and systems at the Division. The old 
Systems were primarily oriented toward accounting applications and were 
run in batch mode resulting in data that tended to be rather stale - 
showing what happened, rather than allowing anticipation of problems and 
opportunities. 


Division Management decided that large benefits would be realized in 
the development of a Marketing Information System. A task force of users 
was then formed to define the detail system requirements. All major 
functional areas of the Company participated in this task force. Their 
efforts gave birth to a system we call Direct Order Entry System or "DOES". 
"DOES" encompasses the ESB-Exide Data Collection and Order Management 
System. It was the intent of Management to improve the order process from 
closing of the sale to customer delivery. The by-product of "DOES" is 
improved information flow to management as well as reduction in adminis- 
trative costs. | 


The end product of the task force was a designed requirement document 
which delineated all the elements a Marketing Information System should 
contain. This document was written by the Systems Department and extensive- 
Ty reviewed by the user task force. 
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It was determined that in-house expertise was insufficient for the 
installation of a major on-line order entry system. Both software and 
hardware proposals were solicited from outside vendors. The proposal 
was sent to about 12 vendors which included software and hardware combina- 
tions such as DEC, Data General, Hewlett-Packard, and Corporate Computer 
Center - the latter consisting of NCR and Data General. The major 
determinant in the selection of HP as the vendor was the availability of 
the high level languages COBOL, RPG, FORTRAN, and their IMAGE data base 
software. 


The design and development phase began in June 1976 with delivery of 
the CX System to the software house for development. The project was 
scheduled for completion by the end of 1976. However, the project began 
Slowly due to changes in personnel at the software house, and because of 
Changes that we were making. After several setbacks, the project finally 
took off in November, 1976, and the system was delivered to our Horsham 
location in August, 1977. 


Within two weeks of the system's delivery, we began entering orders 
on the system and started printing our invoices for a small segment of our 
business. Within a couple of months, it became obvious that the CX could 
not handle the workload nor could it perform all the functions we desired 
of the system. An upgrade was made to the Series II in February, 1978. 


We currently have the HP-3000 Series II with 512 k memory, (1) HP7905 
15 megabyte disk, (1) HP7920, 50 megabyte disk and (1) 47 megabyte disk. 
There are 14 on-line order entry and inquiry terminals, 4 terminals for 
System development and one on-line terminal printer. We also have a 600 
line per minute printer and a card reader. This upgrade improved the CRT 
response time to an acceptable level. 


SCOPE 


Marketing Information System "DOES" controls the order from initial 
receipt to final invoicing of the product. 


1. The order entry covers three distinct products and 
meets the order entry needs of multiple market places. 
It can be as simple as entering a catalog number or as 
complex as actuallly designing the final configuration 
of a total battery installation. 


2. Reservations can be made against batteries and chargers 
located in one of the 34 Service Centers or in transit 
to the Service Centers. The salesmen can inquire of product 
availability at the plants in transit, and at all the service 
stations, by calling the Customer Service Center in Horsham. 


3. Assignments of firm customer orders are made against stock 
orders that are being produced at our plants. This is not 
an automatic function. An operator has to review the CRT 
display and then select the order she wants assigned 
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based on its need date and availability. 


4. Shipments are entered and invoices are requested 
each day. In addition, each order is checked on the 
CRT against the customer purchase orders. 


5. Customers can call and make inquiries on the status of 
their orders. Multiple keys are used for simplifying 
the order search. Since this is the most frequently used 
function, we designed it two ways; one is part of the 
"DOES" system; the other is a stand-alone inquiry routine. 
Since "DOES" requires heavy overhead to run, we hope to 
reduce the resources required. 


6. Each day operational reports such as invoices, acknowledge- 
ments and shipping documents are printed for mailing the 
next day. In addition, various documents are printed to 
control paper flow at the Division. We have reduced the 
number of internal copy order distributions from 48 to 12. 


7. End of the week reports are prepared on gross profit re- 
garding orders received, discount analysis and freight 
allowances given. 


8. Monthly reports consist of a sales backlog. Future plans 
include a profit backlog. 


9, The users are writing their own QUERY programs for on-line 
inquiry of backlogs, order assignments and the amount of 
business generated from a given customer. The QUERY is used 
to make ad-hoc reports for management. The only complaint is 
that they can't cross data sets. 


DESIGN CONCEPT 


The system is divided in two major parts; the on-line, which is 
available from 8:30 a.m. to 5:00 p.m. and the batch phase, which jis 
run from 5:30 p.m. to about 8:00 p.m. We would not start the on-line 
function unless there has been a successful completion of the batch 
process the night before. This separation of functions insures that 
we do not have problems with cut-off dates. 

There are three data bases on the system: Open Order, Product and 
Customer. The Open Order data base duplicates all the products and 
customer information for each order. The Customer data base, in addition 
to containing customer information, contains reservations and avatlability 
of orders at the plants. The product data base consists of all the 
product information and freight rate tables. These data bases were selected 
in order to prevent excessive contention on one data base due to the 
requirement of locking at the data base level. Therefore, there's no 
Contention between entering orders and product availability inquiries. 
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The languages used are FORTRAN for the on-line application, COBOL 
to extract information from the data base and RPG to prepare various 
reports on the extracted program. A special screen monitor is used to 
control the writer and reach to and from CRT's, and to call application 
routines. Block mode (page) is used to transfer data from the screen 
to the computer at 2400 bd. All transactions that update the data 
bases are logged on a single transaction file. A special recovery 
program is used to rebuild the data base by applying the logged transactions 
to the most recent back-ups. The on-line module consists of 62 code 
segments. The largest is 6700 words, the average is 2000 words. The 
total size of the on-line module is 124k words. The data stack is 
approximately 8k words of which approximately 5.3k words are the global 
area (FORTRAN common). 


Communication with the CRT's, updating of data bases, and editing 
of input data are centralized in three of the 62 segments of the "DOES" 
manipulation. As a result, more than 90% of the time required to process 
a transaction is spent in one of these three segments. Since we are 
dealing with a re-entrant (or code-sharing) system in the HP-3000, this 
allows a great deal of efficiency to be gained as these three segments 
tend to remain in memory. Thus, we have decreased the amount of memory 
we would normally require, and decreased the terminal response time. 


The batch program consists of about 40 different programs and each 
program performs a specific function. No attempt was made to utilize 
One program for multiple functions. This concept has allowed us to make 
changes to extract and report with minimum impact on other programs. 


SPECIAL FEATURES 


1. Every night we notify 18 sales offices of the number of orders we 
have received from them, any reschedules and special shipments that 
are authorized on their location. The achieved objective was to 
reduce the incoming phone calls since all the information was 
available at the sales offices. 


2. In addition, each of the CRT operators can transmit administrative 
messages to respective sales offices or a general message to all of 
the sales offices over the TWX network by Utilizing a "DOES" function. 


3, A special subroutine was written to estimate freight which is based 
on Ship to Zip Code, weight and FOB point. If the customer requests 
the freight invoice, we utilize this subroutine to prepare him an 
invoice at time of shipment. 


4. Our field offices have the capability to TWX orders into a central 
TWX machine where a paper tape is generated for subsequent batch update 
of the data base. 
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COMMUNICATIONS 


1. Every night we transmit shipping documents and bill of ladings 
to Data Point to our plants using IBM 3780 protocol. 


2. Every night a specially formated file is transmitted using IBM 
3780 protocol to Western Union Data Center in Virginia for 
distribution of daily newspaper over the Western Union TWX 
network. 


3. The HP is also used for transmission of information to our IBM 
148. The protocol used is 2780. 


FUTURE PLANS 


We are currently in a phase where we are building our data bases by 
order only. The next phase will be to utilize this information for 
management reports. 
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Computerized Word Processing 
a a Presentation for the 
7 


— International Meeting of the 
HP General Systems Users Group 
Denver Colorado, November 1978 


by 
Martin Gorfinkel 
Los Altos Research Center 
339 South San Antonio Road 
Los Altos, California, 94022 USA 


Description 
A Computerized Word Processing System captures documents in machine 
readable form as they are first typed. The machine readable form 
allows changes to be made in a document without retyping. 
Formatting instructions are stored with the document or can be 
changed after input of the document to allow output in various 
formats - again without retyping. 


Capabilities vary greatly from one system to another. Some key items 
are: ease of handling large documents; ease of integrating the word 
processing with other computerized functions; the variety of out put 
and input devices available for use with the system; and the ease of 
use of the system. 


Advantages 


Material is typed manually only once; the time and errors involved 
in retyping is eliminated. Reports from other computerized systems 
can be automatically integrated into the word processing product. 
(Financial tables and mailing addresses from a data base are two 
examples.) A greater variety of format between documents and 
consistency within documents is easier to attain. Collaboration in 
writing and editing among several authors is facilitated, 
particularly when the authors are in different locations with access 
to the same computer. 


The dis-incentive to make last minute corrections or improvments to 
a document is removed. The final copy is produced quickly, neatly, 
and without introduction of new errors. 


A well designed system will be easy for clerical and secretarial 
staff to learn and to use. The system should adapt well to both 
intensive and casual use. 


Features 

Features which can provide additional benefits to the user include: 
incorporation of one document within another; formatting of numeric 
tables and calculation of totals on those tables (saves proof 
reading the numbers); inclusion of the current date as a document is 
printed; flagging lines changed or inserted; automatic generation of 
an index and/or table of contents; and an encryption scheme to 
protect the confidentiality of sensitive documents. 


sample Applications 
Program Development and Documentation 


Technical Documentation 

Proposal and Contract Writing 
Letter Writing and Mass Mailings 
Financial Report Writing 
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DOLLAR-FLOW: FINANCIAL PLANNING ON THE HP3000 
(users write their own programs) 


By Jack Damm, Principal, The Palo Alto Group, Sunnyvale, Calif. (408) 735-8490 


Good afternoon. I am going to talk about financial planning on the 
HP3000 with the Dollar-Flow planning language. My discussion will focus 
on three areas: 1) What financial planning is, and why there is a need for 
computerized planning; 2) Design considerations for "friendly" user- 
oriented applications; and 3) How the language Dollar-Flow is used for 
applications like profit planning. 


THE NEED FOR FINANCIAL PLANNING 


First, let's start with two questions: What is financial planning? 
And why is it necessary? Financial planning is making decisions about allo- 
cating the scarce resources of an organization so as to best achieve its 
goals. In the private sector, this usually means how best to allocate money 
and people to achieve profitability goals. In the public sector, it may mean 
how best to allocate people and dollars to provide a desired level of Service. 
The main idea here is that the resource is scarce and, aS a manager, hard 
decisions have to be made about how to use it. More specifically, financial 
planning is setting budgets, making pricing decisions, and estimating future 
demand for products and services, in order to achieve profit and/or perfor- 
mance goals. 


Why 1s formal planning necessary? First, of course, because a scarce 
resource (typically money) is involved. If we had enough money for everything, 
then we could simply raise our salaries and retire early. Secondly, it is very 
important to have general agreement within an organization about how goals 
are to be achieved. No assumptions should be made without clearly stating 
and documenting them. With a good financial plan, trouble signs can be 
Spotted earlier and corrective action taken sooner. Businesses which fail 
to plan effectively are the best illustration of the need for planning. 


Let me offer one last reason why planning is important. For many 
companies, planning is a necessity because of the complexity of their opera- 
tions. A typical manufacturing company may purchase thousands of parts for 
use in a vast array of products, and assemble them in many different locations. 
They cannot wait until there is no money in the till to decide that its time 
to raise prices. And our current rate of inflation makes this an even more 
important consideration. 


THE TYPICAL PLANNING PROCESS 


Okay, let's assume that you accept the need for financial planning. 
So what's the big deal? Well let's look at the typical planning process and 
I'l] show you. 


First, planning involves lots of numbers. And these numbers change 
often. Financial planning involves projections into the future and is 
a very uncertain process. When you're uncertain, then you have to do contin- 
gency planning. Play "what if" games. What if sales are 20% higher than 


planned? What if the cost estimates are too optimistic? What if our product 
sales mix is different? Because of uncertainty, alternative plans are neces- 
sary, increasing the amount of work required to plan several times over. 


And that's not all. The attempt to reach a targeted objective such as 
profit adds to the work. It may take several passes before all of the budgets 
combined with the sales estimates, cost estimates, and so forth, sum up to the 
desired results. The task soon becomes monumental. 


The following is not an uncommon occurrence: You work many hours pre- 
paring budgets and doing sales forecasts. With a board meeting just a few days 
away, you finish your plan. The company president takes one look at the re- 
sults of the combined numbers and gives it back, requesting a 15% cut in the 
budget. You prepare a revised budget, repeat all of the calculations, this time 
under increasing pressure to get the job done fast. The day before the board 
meeting, marketing revises the forecast. All of the budgets must be revised 
again. And now it is getting late into the evening the day before the meeting. 
Everybody is getting tired. After a few more iterations, exhaustion sets in. 
The planning process finally ends. With a good plan? No, with exhaustion. 
Does this seem like a doomsday tale? It's not. I've see this happen many 
times. No wonder people dread budgeting time. 


Combine the sheer effort required to effectively plan with the require- 
ments for a good plan: It must be TIMELY. In a dynamic, growing company, a 
plan must reflect todays expectations, not yesterday's. It must be ERROR FREE. 
Late-night, reworked plans suffer from simple calculation errors. Errors due 
to using the wrong set of estimates, because they keep on changing. Imagine 
the embarrassment of a summation error. And with all this, the plan must remain 
FLEXIBLE. I worked on a profit plan for a company a few years ago which added 
an entire product line between iterations of the plan. And finally, when you 
are all done, a good plan must be WELL DOCUMENTED. What factors were used for 
overhead? What was the basis for the final sales figure? How was a particular 
number calculated? All too often, there is little documentation on how a plan 
was actually prepared. 


To summarize: A typical financial plan involves lots of numbers, which 
change often. The need for many iterations makes this process time consuming 
and exhausting. At the same time, the plan must be timely, error free and 
well documented. In short, good financial planning is not easy. 


WHAT IS THE BEST WAY TO PLAN? 


Given that this is the nature of planning, what is the best way to 
plan? How can it be done with a minimum of difficulty? Traditionally, there 
have been two ways of planning. Planning by hand (and calculator) and planning 
uSing the computer. Let's take a look at both of these methods and evaluate the 
pluses and minuses of each. 


Preparation of plans manually has several drawbacks. First, because of 
the amount of data involved and the number of iterations, it is slow and time 
consuming. After many iterations, accuracy becomes a problem. The wrong es- 
timates may be used, particularly if they keep changing. Calculation errors 
seem to increase with each iteration. And documentation is usually not very 
good. 
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On the other hand we have financial planning on the computer using the 
traditional programming languages like BASIC, FORTRAN, or COBOL. Once set up, 
a model written in one of these languages will run on the computer in a matter 
of minutes or seconds. Great! But here's the catch. The model will run very 
quickly once it has been set up, but it may take months to get it developed. 
And you need a programmer. Let's see what can happen. You start your plan 
well in advance of the next budgeting cycle. With six months lead time you give 
a precise set of specifications to an enthusiastic programmer who dutifully sets 
about coding your model. At the end of the first three months, he comes back 
to you with his first try. You patiently point out where the model is not 
consistent with the specifications, settle on a set of revisions, and the - 
model is reprogrammed to your satisfaction. All set, right? No. As you begin 
uSing the model, the company president starts to change his mind (even though 
he reviewed the original specifications). Add a decimal place here, another 
line item there. Why aren't all twelve columns of data on the first page? 
Frustration. 


What is the moral of our story? Programming a planning application 
with the traditional programming languages lacks flexibility. The programmer 
needs lead time to set up the application and has difficulty in reacting to 
short term changes. How about adding another division to a multi-divisional 
company? Try changing every format statement in the model in an hour. And 
add to that the bother of documentation. 


To summarize, manually prepared plans can be flexible, but they take 
a long time to do and lots of effort, especially if several passes are done. 
They often lack documentation. Planning with traditional programming lan- 
guages takes too long to set up, is inflexible, and requires the services of 
a programmer. 


PROBLEM ORIENTED LANGUAGES 


Let me digress for a moment. For several decades now, computer scien- 
tists have been searching for a "universal" programming language. ALGOL? 
PL/I? APL? The search goes on. Each has its merits, each its disadvantages. 
But these "procedure oriented" languages have one thing in common: You have 
to be a programmer to use them. And it is altogether too easy to include bugs 
in even the simplest of programs. As long as there is a programmer acting as 
middleman between the user (or analyst) and the computer there are going to be 
communication problems. Maintenance problems. Resource and priority problems. 


What's the answer? A planning oriented application language which 
incorporates the good aspects of traditional programming, but eliminates the 
problems. Where plans can be set up and revised easily, without having to be 
a programmer. What I am describing here is one example of another class of 
programming languages, "problem oriented" languages. Languages which have been 
designed to provide solutions in a general way to classes of problems. Simple 
enough to be used by non-programmers. Easier to debug. Self-documenting. 
QUERY is an example of a problem oriented language. It provides ‘access to 
IMAGE data bases in a fashion simple enough to be used by non-programmers. 
Dollar-Flow is a problem oriented language, designed as a tool for non-program- 
mers who want to set up tabular planning reports. 
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Financial planning is an area well suited to problem oriented languages. 
There is a considerable amount of generality in what planners do, although no 
two plans are the same. A financial plan typically involves mathematical 
operations on rows and columns of numbers. With well defined rules for the 
ealculations. And the burden of planning in any other way give the financial 
planner considerable incentive to try new approaches. 


This is a good start. But we still have to get the planner onto the 
terminal and communicating with the computer. How is this done? By giving him 
an effective tool. One which is both friendly and enables him to get the job 
done in a way that he understands. 


DESIGNING FRIENDLY SYSTEMS 


This leads us to the next point: What makes a system "friendly"? 
How can a system be designed so the novice or non-computer type feels com- 
fortable with it? I offer here a few of my ideas and techniques for develop- 
ing friendly systems. 


SIMPLICITY 


Keep the system simple at all cost. Do not let the internal struc- 
ture on the computer dictate how a system looks to the user. Let him express 
his ideas in his own terms. For example, the original design for the Dollar- 
Flow language was based on a set of documentation which I prepared for a group 
of accounting types. This documentation described the workings of a particular 
customized model on a line by line basis. I figured: What could be a better 
set of design specifications for a language than actual documentation? As you 
document your model you are also writing your program! Another example. 
Dollar-Flow re-orders calculation rules automatically. Thus, line 1 on a report 
can reference data on line 10, which, in turn, can reference data on line 20. 
Dollar-Flow automatically figures out the prcper sequence for calculations 
(calculate 20, then 10, then 1) without any intervention by the user. 


It 1S important that the application be self documenting. For example, 
Dollar-Flow is a menu driven system. At each step of operation, the user knows 
his alternatives. There is little need for a "pocket guide" to the language. 
This 1S not to say that there is no need for manuals. A good manual is impor- 
tant. But it is a fact that few people actually read manuals. The less a sys- 
tem forces a user to read the manual, the more usable it will be. 


Not only should the user be told what his alternatives are, the system 
Should also help him to choose the proper response. Throughout the Dollar-Flow 
prompts, the most likely response is shown in brackets as the "default" res- 
ponse. In some cases, he can use the default response without bothering to 
even understand the question! For example, the prompt: 


USE STANDARD OVERALL REPORT FORMAT (<Y>,N,W-WIDE PAGE)? 
In one brief prompt, the user can see his options and pick one. A simple car- 
riage return will cause the system to use the default response. And his entire 


report format is set up. No PRINT USING or FORMAT statements. Very simple. 
And it can be changed easily. As the user becomes more familiar with the 
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language, he can begin to exercise more options. With an 'N’' response, Dollar- 
Flow leads the user through a review of the many formatting alternatives. 
Report formatting can even be done on a trial and error basis. Start off with 
the standard format, then change the column width or number of decimal places 
Shown as needs require. 


As I already mentioned, the design for the Dollar-Flow calculation 
rules was based on a set of user oriented documentation. Ask a user to describe 
how the values on the report are to be calculated in his own terms. With the 
addition of a few quote marks here and there, he has already written a program 
in the Dollar-Flow language. Self-documenting languages not only save the 
effort required for documentation, but make debugging much easier. 


One last comment about simplicity. Save the user concerns about 
internal structure through structure independent (or data base) approaches 
to data relationships. One of the beauties of QUERY is that the user doesn't 
have to concern himself with all of the details of the data base to get a sim- 
ple report. In Dollar-Flow, all reports are programs, al! saved programs are 
files, and all save files contain reports. To reference data on a Saved 
Dollar-Flow report, simply indicate the line name and the report save file 
name: 


MARKETING BUDGET = ‘BUDGET’ OF 'MKTG'; 


There is no need for the user to know how the data is stored or even which 
line on the 'MKTG’ report is the 'BUDGET' line which he is using. 


ERROR HANDLING 


Okay, so let's say you have implemented a simple system. Does this mean 
that users won't make mistakes? Of course not. In fact, the friendlier a 
system is, the greater the likelihood that the users will not be computer types. 
So, keep in mind that “to err is human, to forgive is good systems design." 
Of course, you must edit all inputs. But then use a friendly approach when 
the user has made an error. Because Dollar-Flow is menu driven, simple typing 
errors cause the system to repeat the prompt. Errors of a more complex nature, 
Such as where a report is referenced but does not exist, generate intelligible 
error messages. Along with each error message give a message number. And 
provide a glossary with the documentation which gives even greater detail on 
the possible cause of the problem. 


At the same time that it is informative, a system should help the user 
to work around problems. For example, in the case of an invalid report refer- 
ence in Dollar-Flow, the user can interactively specify a different report 
name, or values, or zeroes. He can also indicate that computation should cease 
after a scan for further errors. Again, unless a particular error is extremely 
serious, warn the user and proceed (with his permission). Another example. 

As far as the mathematician is concerned, division by zero gives unworkable 
results. In Dollar-Flow, division by zero yields ‘invalid’ numbers (which 
print as asterisks), but doesn't stop computation. It's amazing how much more 
Satisfying a user finds a report filled with asterisks than just a list of 
error messages. At least he can look at the format to see if it's to his lik- 
ing. 
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If you must tell the user that he has made an error, tell him as early 
as possible. One of the most enlightened things done by the MPE operating 
system is to edit the job card image when a job is being streamed from an inter- 
active session. It sure is better to find out right away than waiting for 
the job to begin execution to find out that a simple error has been made on 
the JOB statement. Report development in Dollar-Flow is completely interactive. 
If a user is setting up a report and he enters a calculation rule with invalid 
Syntax, the system responds with a message immediately, and permits him to edit 
his error (not unlike the BASIC interpreter). It is not necessary to go into 
the computation step to find many errors. 


MAINTENANCE AND SUPPORT 


Let us assume that as an enlightened designer of friendly systems you 
have now designed and implemented your masterpiece. Are you done? Of course 
not. This is only the first step. There are two more important aspects which 
are critical for good, friendly systems: Continuing improvement and good sup- 
port. Let me talk about continuing development first. No system is great on 
the first try. I am a believer in the iterative approach to systems develop- 
ment, if you can afford it. I am not talking about sloppy design. I am talking 
about the tremendous wealth of ideas that you can get from your users, AFTER 
you have implemented a system. Try to be receptive to the suggestions of your 
users (even if they are infeasible). Never give a critical user the impression 
that you think he has just offered a bad idea. Go out of your way to solicit 
ideas from your users. If the situation merits it, get involved in several of 
their applications. You can learn about ways the system is being used that you 
never thought about. Ways in which its use may be awkward. Which messages are 
more annoying than useful. Which features are badly needed. I send periodic 
questionnaires to my users (some of them even respond). This helps to priori- 
tize new features. And users group meetings are a great boon to information 
flow. 


How should this wealth of new ideas be integrated into an already deve- 
loped system? Carefully. Do not rush a new version of a system out to users 
just because they need a particular feature. You must let a new version of a 
system be "burned in" first by a test site. Software bugs cost you credibility. 
Once lost, credibility is very difficult to reestablish, so reliability is 
extremely important. After all, would a user prefer a system with the bells 
and whistles he wants but doesn't work, or one which works with a few less fea- 
tures? 


Speaking of bugs and user suggestions leads me to the question of sup- 
port. There is nothing more frustrating to a user than to get 95% of the way 
to his computer solution only to be stopped by the application package he is 
using. For any reason. If you can afford to do it, good support pays great 
dividends. Dollar-Flow is supported in an “on-line” fashion. This means that 
if a user has a problem, he picks up the telephone and calls. If his problem 
is with an existing report, I may even log onto his system and take a look at 
that report. This kind of support not only helps to find and eliminate system 
problems quickly, but I also find out about areas where the documentation may 
be confusing (or incorrect). Where another feature might simplify the users 
application. In short, on-line support can be another source of good ideas 
from users. 


Let me summarize these techniques for creating friendly systems. First, 
KEEP IT SIMPLE. Try to think like the user instead of a computer expert. Use 
his terms. Assume that he won't read the manual. Try to make it self-explana- 
tory. Second, be INFORMATIVE but FORGIVING with your error handling. Edit all 
inputs, but don't bother the user with minor errors. When the application 
merits, CONTINUING ENHANCEMENT will make a much more usable system. Respond to 
user suggestions. But exercise good judgment in the trade-off between adding 
new features and degrading SYSTEM RELIABILITY. 


PROFIT PLANNING 


I am not going to take too much time on the last part of my talk. I 
am just going to show you a few sample reports prepared using Dollar-Flow. At 
the risk of violating my agreement not to make a sales pitch, 1 invite you to 
visit the PALO ALTO GROUP's booth on Wednesday for a demonstration of Dollar- 
Flow in action. 


Let me first describe to you the typical company profit planning cycle 
and the environment in which a planning tool like Dollar-Flow is used. The 
typical Dollar-Flow user is the accountant or company controller who is respon- 
sible for preparing the reports. Not a programmer. Most users are working on 
in-house HP3000 systems. With access to CRT's and a system line printer nearby. 
Reports are written interactively, and manual inputs are also entered via the 
terminal. Usually, reports are printed on the CRT for review then saved when 
the user is satisfied with the report. If hard copy is desired, the reports can 
be routed to the line printer. For generating large numbers of reports, the 
“batch command mode” is used, where with very little terminal input a large 
number of reports can be generated. 


Profit planning typically begins with a preliminary sales forecast. 
Preliminary. Sales forecasts always change. And at the last minute, too. 
Often the sales forecast is done on a product-by-product basis for the first 
year or so, then combined with overall! dollar sales projections further in the 
future. The near term unit forecasts are sometimes adjusted based on an over- 
all dollar figure. The forecast is iterated several times. To make a change, 
the product manager just runs Dollar-Flow, inputs whichever figures have chang- 
ed, pushes a few buttons, and the new sales forecast is ready. Since many 
parts of the profit plan depend on this sales forecast, the typical plan is 
usually set up with reports referencing the sales forecast report. If the 
figures are changed on the sales forecast, these changes will be automatically 
reflected on the other reports the next time they are run. Some manufacturing 
companies even use a multi-level sales forecast step, where a build plan (or 
production plan) is generated from the sales forecast. 


Meanwhile, departmental budgets are prepared. Some Dollar-Flow users 
centralize the budgeting function and only distribute budget worksheets to each 
department or location. This is usually done if there are only one or two 
budget iterations. On the other hand, some of my customers distribute the bud- 
get preparation, with each location setting up its own budget in Dollar-Flow. 
In this case, figures can be input to Dollar-Flow, changes can be made, and 
several iterations of the budget can be done all in a matter of minutes. And 
budget consolidations are fun! With a few simple commands to Dollar-Flow, a 
whole series of budgets can be consolidated into a departmental or divisional 


budget. When changes are made to the low level budgets, they automatically are 
reflected on the consolidated budget the next time its run. 


The profit/loss projection is next. Using the data from the sales fore- 
cast, the build plan, and the budgets, and adding factors for items like sales 
discounts and returns, a pro forma operating statement is prepared. Often, the 
bottom line (profit) on this report determines what (if any) changes need to be 
made to the budgets. With a flexible tool like Dollar-Flow, a financial execu- 
tive can even do sensitivity analysis: What if sales are 20% lower than fore- 


cast? What if our discount schedule is more aggressive and our volume is 
larger? 


Some companies that rely on substantial amounts of debt to finance their 
operations combine the profit/loss projection with a cash flow projection. 
This is because interest paid (an item of expense on the profit/loss statement) 
has an impact on the amount of money required to run the business. This deter- 
mines the level of borrowing, which, in turn, affects the amount of interest 
which is paid. Dollar-Flow, and most good financial planning languages, can 
solve the "simultaneous equations" this circular logic represents, and determine 
a level of debt and debt service which are consistent with each other. This 
is far more difficult when done manually. 


Another procedure which is laborious when done by hand is the aging of 
accounts receivable and accounts payable projections. Using Dollar-Flow, once 
the rules for aging have been set up, a change in the sales forecast or the 
build plan will automatically be reflected in new receipts and payables pro- 
jections. 


And, finally, some companies prepare pro forina balance sheets as the 
last step in their profit planning cycle. This is not necessarily the way all 
companies plan. Or even the way all Dollar-Flow users plan. In fact, many 
Dollar-Flow users are not even responsible for profit planning. Instead, the 
system is used for a wide variety of ad hoc applications involving calcula- 
tions on rows and columns of numbers. It is even used as a design tool for 
systems which will later be hard-coded in COBOL, FORTRAN, or BASIC. 


Some of the other applications of Dollar-Flow that I am aware of in- 
clude: 


Product pricing. Comparing alternative prices for a single product 
(the plotting capability is great for comparisons). Or comparing profit per- 
centage across an entire product line. Financial ratio analysis. Comparing 
selected financial ratios against industry standards or company objectives. 
Capital budgeting. Rates of return and discounted cash flows can be calculated 
easily using built-in financial functions. 


Performance reporting. Variance reports showing actual budgets or 
profits versus plan. How sales are doing against target. (One Dollar-Flow user 
generates 500 graphs every quarter showing product line sales performance for 
every branch of every distributor who markets his products! ) 


SUMMARY 


Let me leave you wish a few parting thoughts. Financial planning is 
not an easy process. Figures change. The whole approach to a plan may change. 
And you need your results yesterday. Traditional systems design and program- 
ming methods are not going to be effective in this kind of situation. Use a 
better approach. With a friendly, problem oriented planning language like 
Dollar-Flow, applications nightmares can become applications successes. 


Considerations for a Typist Oriented, 
Fully Integrated Wordprocessing System 


by 


DARYL A. FRAME 
and 
ROGER M. GOLDMANN 


COMARCO, Inc. 
227 W. Hueneme Rd. 
Oxnard, California 93030 
(805) 488-6441 


Wordprocessing systems are the glamour products in today's office equipment market. 
However, until very recently, Wordprocessing has for the most part been ignored by Data 
Processing managers and personnel because they did not recognize that they could offer service 
to departments which by nature perform labor intensive, repetitive tasks. Typical departments 
which have seemed unlikely candidates for Data Processing services are Office Administration 
and Office Services.' 


It is extremely doubtful that this situation can continue much longer. Without the help of 
today's latest computer technology, these formerly non-Data Processing departments will 
become buried in the avalanche of paperwork which now passes through them (Fig. |). In some 
organizations, Data Processing personnel are already being called upon to assist in selecting 
Wordprocessing equipment or software. This really should not be too surprising, since the 
technologies used in Data Processing and Wordprocessing are too similar to ignore. 


A few years ago, the typical office accounted for only a fraction of the total company 
budget, however, this is no longer true. Greater demands are being placed on office personnel 
and therefore higher wages are required. This has a tendency to increase the cost of all office 
services (Fig. 2). Without new methods, the future prospects reveal more increases in cost 
without any appreciable increase in productivity (Fig. 3). 


On the other hand, costs within the Data Processing field appear to be declining 
(Fig. 4).2 The needs of formerly non-Data Processing departments cannot be ignored. As more 
and more demands are placed on them, the need to apply technological expertise will be 
mandatory. 


However, there is a significant problem. Based on a qualitative survey conducted by 
Starch INRA Hooper, Inc. during May and June of 1977, “corporate decision-makers are neither 
sufficiently knowledgeable nor comfortable” with the concept and application of 
Wordprocessing and they feel that “while the industry ra/ks the system concept, it actually 
sells pieces of equipment.”3 
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THE PROBLEM 
EVOLUTION REVOLUTION 





OFFICE COSTS 


@ WERE 20% TO 30% OF TOTAL 


e NOW 40% T0 50% 
— DEMANDS FOR MORE INFORMATION 
— PAPER EXPLOSION 
— RISING SALARIES 


e AVERAGE SECRETARIAL SALARY 68% HIGHER 


e AVERAGE LETTER COST 40% MORE THAN 10 YEARS AGO 


Fig. 2 
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When you consider that there is not even an industry accepted definition for 
“Wordprocessing”, it comes as no surprise that management level personnel would be somewhat 
bewildered. At the risk of being presumptuous, I will attempt to define Wordprocessing as a 
“Work Cycle”. This work cycle includes dictation, formatting, typing, text manipulation, 
proofing, revising, and printing. Based on this definition, Wordprocessing or the processing of 
words, exists in every office, whether it is automated or not. 


Automated Wordprocessing, though, has a number of distinct advantages over the 
manual method. Cost saving is perhaps the most important and obvious need. It has been 
demonstrated time and again that Wordprocessing can return a substantial savings. One recent 
example appeared in the September 1978 issue of Datamation magazine.4 The cost per page 
using the manual approach was listed at $11.24, whereas, with automated Wordprocessing, the 
cost was $6.42. This represents a savings of $4.82 per page or nearly 43%. In addition to these 
savings, there are real savings in time when using automated Wordprocessing. Typewriter 
prepared documents were estimated at 75 minutes per page to produce the first draft, 
coordination draft, and final copy.4 With Wordprocessing, however, the same steps required 
only 27 and one half minutes per page, a savings of 47 and one half minutes per page or 63%. 
With today’s higher paid office personnel, such savings in time represent significant savings in 
money. As a result, the need to hire additional personnel may be deferred due to greater 
individual productivity (Fig. 5). 


You can appreciate that while Dataprocessing costs in 1973 were $26 billion, those of 


office administration processing were $42 billion.5 This indicates that a great deal of work can be 
done to automate the modern office. 


THE SOLUTION 


REVOLUTION 





1870 1900 1940 1980 
Fig. 5 
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Consider also the quality and speed of a good Wordprocessing system. Not only does it 
produce error-free originals, but every character is captured and stored. preserving the 
document for future use and thereby shortening the turn-around time for revisions. Every 
revision cycle is apt to require progressively less and less time with every Output copy being 
flawless. 


Today's Wordprocessing marketplace has every imaginable type of product available. 
These range from simple standalone hardware units to massive software systems which run on 
the largest of main-frame computers. The technology is such that whether you are generating 
single page letters or complex technical publications, systems are available. Your organization 
may or may not already be involved with one or more of these systems, but in choosing a future 


system, it is essential that it be an extension of techniques with which the users are already 
familiar. 


The fact is, there are only four (4) basic types of Wordprocessing systems available 
today.” An understanding of these categories will help in evaluating the pros and cons of your 
existingfuture systems. 


I. Standalone Hardcopy- 
This includes all types of automatic typing devices that use magnetic media to 
capture and store what has been typed. Although the single-unit cost is modest. 
these systems cannot be integrated for several operators to share resources. Their 
capacity is limited and they are very inflexible. These units are generally used for 
short documents. 


i] 


Standalone Video Display- 

This equipment possesses a video display capability ranging from part of a line to a 
full 66-line legal-size page. At times this type of equipment has text editing 
capabilities and may include some Data Processing capabilities. A number of 
products in this category are direct crossovers from the intelligent terminal portion 
of the Data Processing industry. Again, while the capabilities of this type of 
equipment is greater than for standalone hardcopy units, it is by nature 
non-shareable between users and _ still limited in capacity and flexibility. 


3. Time-Shared Services- 
This is an arrangement in which one or more terminals (which may be owned or 
leased) are hooked into a service company’s computer to provide an economical 
alternative for users who occasionally require sophisticated capabilities. or who are 
taking a tenative first step toward Wordprocessing technology. 


4, Shared-Logic Processing- 
Several independent stations are linked to a single central processing unit for 
increased capability and storage at a lower cost per station. This is the type of 
system we might envision with an HP 3000 at the hub. 


Few organizations set out to procure a computer based on their Wordprocessing needs. 
Instead, they quite often have an established Data Processing department running payroll, 
general ledger, cost accounting or other “standard” computer applications. Let's examine the 
benefits of adding a Wordprocessing system to this already existing hardware. 


First of all, Wordprocessing allows greater use of existing equipment, which may be idle 
part of the time anyway. Because we are very cost conscious, this type of extra duty from 
hardware already in place rarely meets with criticism. And since few, if any, equipment changes 
would be required, no interface problems are encountered in dealing with another hardware 
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vendor either. A great deal of time and effort is generally consumed just familiarizing with new 
equipment. So, it is a real asset if the end users do not have to be retrained on a new piece of 
equipment when a Wordprocessing system is installed and they are more likely to respond 
favorably to new systems implemented on existing equipment. 


When looking at Wordprocessing then, what are important considerations? Two main 
areas of concern are paramount: 


l. It must be typist oriented. 
2: It must be fully integrated. 


At Comarco, we have been producing text editing software for the U. S. Navy for a 
number of years. When we undertook development of WORDWRIGHT €, our general purpose 
commercial Wordprocessing system, we placed these two items at the top of our list of 
requirements. Data Processing personnel can get along fine with “computer” terminology. 
Secretaries and typists though do not (and do not need to) speak “computerese”. They simply do 
not respond well to such systems. In terms of being fully integrated, we felt that it was 
important that the user not always be changing gears, so to speak. You no doubt have 
experienced the frustration of constantly skipping around from one “sub-system” to another. 
Because this situation is common, some corporate decision-makers apparently have remained 
cautious about Wordprocessing. 


This is not to say that systems which are not typist oriented or fully integrated cannot be 
forced upon them, but in all fairness, wouldn't it be best to allow the dictates of the end user to 
determine which product will be selected? This process begins with defining the task to be 
performed by the equipment and software.’ Second, consideration should be given to the 
organization's internal operations and established procedures. “Because of the normal resistance 
to change, any new technology introduced should, where possible, be an extension of techniques 
the user is already familiar with.“6 Not just the managers, but the people who will actually be 
using the system should be consulted and their views explored in depth. 


Only after the above steps have been completed should an investigation of what is 
available be made or a design for an in-house developed system started. If you are looking at 
purchasing or leasing, bear in mind that special features, not available on all Wordprocessing 
packages, may be required to provide properly composed technical reports. For instance, 
automatic alignment of decimal points for tabular data, right-hand justification or automatic 
hyphenation. You might also require a dual pitch feature for ten or twelve characters per typed 
line inch. 


Does the system provide for true document management? The ability of a 
Wordprocessing system to track existing documents and catalog names, dates and current status 
eliminates the associated manual bookkeeping. So, in evaluating whether the system is truly 
integrated, this is one area not to be overlooked. Some organizations maintain a very large text 
base including many documents not frequently referenced. Due to a limited amount of on-line 
Storage, It is essential that the Wordprocessing system include some sort of archival and 
retrieval capability. Again, this feature may not be available on all systems. 


All documents require formating. Formatting includes the setting of margins, tab 
positions, indentation, page lengths, etc. A big asset in a Wordprocessing system is the ability to 
create a standard set of formats—formats which are flexible, easy to define and use. Once 
defined, these formats insure style uniformity from document to document. Some Data 
Processing oriented systems do not allow for stored formats. Instead, the user must embed 
formatting directives directly into the text. This may be acceptable for some applications, but 
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you will find that non-dataprocessing oriented secretaries and typists will not be able to achieve 
the speed in inputting text for which they are being paid. A system which provides the ability to 
utilize stored formats reduces operator keystrokes, detail coding of text and formatting errors. It 
is at the user level that a typist oriented Wordprocessing system must work well. 


Since many organizations produce “form” letters, at least two features must be 
considered. 1) Does the system provide an integrated name and address directory which can be 
incorporated into the body of the text? In providing this capability, is text composed around 
variable length inserts? 2) Are user definable prompts available for a fill-in-the-blank effect? 
Both of these items are valuable options which can speed form letter preparation and at the 
same time eliminate the need for the user to browse through the text looking for the locations of 
the changes. 


In addition to the ability to input text with efficiency and speed, is the need for rapid 
error free original hard-copy. A system should provide for output on various devices. For those 
who require high quality character printing the system should interface to daisywheel or cup 
type terminal printers. When such quality is not required, such as preliminary drafts, the system 
should be able to drive a high speed line printer. Some users of Wordprocessing are interested in 
producing high quality camera ready copy. This requires the addition of a photocomposer to the 
basic system configuration. However, as you can see from this paper, the quality far surpasses 
anything which can be produced on the standard daisywheel printer or even the system line 
printer. The ability of a Wordprocessing system to prepare text for output to a photocomposer | IS 
quite rare on a hardware configuration like the HP 3000. If your organization's requirements 
include this feature, you will be able to take advantage of such things as variable character 
Spacing and a choice of multiple character fonts and sizes. 


Automated Wordprocessing has remained relatively simple to use. Systems have been 
introduced which vary from basic editors to WORDWRIGHT €, which is sophisticated and 
comprehensive. Which one you choose will be a matter your organization will have to consider 
carefully. One thing is for sure—Wordprocessing is a very dynamic field. The time is right for 
automated Wordprocessing! 
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Although there is no graphics software language 
currently supported on the HP3000, many products are 
offered to give the 3000 user excellent business 
graphics capability. One of these products, the 
HP2648A, especially lends itself to business graphics 
because of the terminal oriented nature of the HP3000. 

My purpose here is to explore some ways of applying 
graphics to business applications. In the past, 
graphics have been primarily used in scientific and 
engineering applications because graphics technology was 
developed for those kinds of jobs. The business data 
processing area is on the brink of a new era in data 
reporting through the use of graphics. 

Looking at the users of information output from 
business systems, a hierarchy of job positions can be 


seen as shown in the following chart: 








TOP MGMT. 


MIDDLE MANAGERS 


DEPT. 


MANAGERS 


FIRST LINE 
SUPERVISORS 


PLANNERS 
EXPEDITORS 


MANAGEMENT REPORTING 


STAIRSTEPS 


This hierarchy will be referred to throughout this 
presentation as possibilities for graphics applic- 
ations are explored. 

Of prime consideration for a planner/expeditor 
type person is "How is the output of my department 
doing with respect to schedule?”. In the past, re- 
ports have been available to show at any given instant, 
what the schedule number of output units are versus 
actual output. Typically, there have been time lags be- 
tween reported data and actual output data. These time 
lags make scheduling very difficult. In addition, data 
of this type ignores the time continuum needed to know 
where one stands with respect to remaining schedule and 
time. 

With a simple graph, one can easily tell ata 
glance not only where one stands today but also over a 
time continuum. The fact that the output is coming 
from a terminal oriented system allows the user the 
ability of reporting this information on a “pseudo-real- 
time" basis, thus eliminating the confusing time lags 
between reported and actual. 

Figure 1 would be a good example of a planner's 
tool from a batch type system. The planner should expect 
to get this type of information the day after the output 
actually takes place. The list would point out that 


181 units were output as of the end of M-Day 13, but it 
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would not indicate how the production line is doing so 
far during the current day. 

It may also be a good example of a planner's tool 
from an online system. In this case, the information 
would be much more timely and therefore much more useable. 
The information should be expected to be available at any 
hour of any M-Day, and should be expected to reflect out- 
put already finished during the current day. 

Graph 1 shows this same planner's tool graphically. 
Note that not only does the graph indicate production to 
date, but also gives an excellent trend line to let the 
planner know what needs to be done between now and the 
end of the production period. It answers questions like, 
“Do I need to recommend overtime to management", or "Do 
I have a problem with material flow?". 

Notice also, that during the current day an indication 
is given as to whether the ahead/behind trend is being 
impacted by the current day's production. This indication 
is given by the slope of the graph line during the current 
day. 

While this type of detail information is important to 
the planner, the first level supervision may well be more 
interested in more long-term type information. Again the 
Same progression of data reporting can be seen at this 
level. Figure 2 is an example of year to date type infor- 


mation. The same kind of "timely information" parameters 
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apply to this reporting level. 
In addition, some modelling is in order at this level 
to indicate to management what the year end production 
will be if projected at current production levels. There 
are a number of good forecasting methods which may be 
used to extend the production line out through the end of 
the year or beyond. This kind of information is essential 
for good manpower planning and for good material control. 
Another topic of great importance to first line super- 
vision and also to department managers is that of product- 
ivity. One measure of productivity is "dollars per manhour". 
The method I've chosen to work with here is number of 
dollars transferred from a production department versus the 
amound of labor applied. Going back to our earlier example, 
I've applied an arbitrary price to the units in the graph. 
In addition, I've established an arbitrary standard time 
for producing one of the units. This new data is represent- 
ed in chart form in figure 3. Although this is a very sim- 
plified example of productivity measurement, the following 
conclusion can easily be reached: Data of this type can be 
understood much more simply and easily when it is presented 
graphically. Again, the graph which results from this 
data shows a trend over a time continuum. This trend cannot 
be readily gleaned from the same data presented in the trad- 


itional columnar form. 
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Efficiency is another topic of importance to manage- 
ment at this level. Efficiency is derived by comparing 
actual time spent on a unit to a predetermined standard 
time. Efficiency is usually shown as a percentage, which > 
is easily understood as a number and does not need to be 
depicted graphically. But managing efficiency cannot be 
accomplished by a snapshot of any one particular time 
period. Here again, a group of percentages spread over 
time is needed to spot trends. With a computer, the cur- 
rent day's efficiency can be reported with respect to past 
days, and probably more important, a moving average can be 
derived and displayed quickly. This kind of information 
is very useful for spotting trends in efficiency to enable 
management to be responsive to developing problems. Figure 
4 shows data of this type. 

Middle and top level management are interested in 
more long-term information. Managers at this level are 
interested in topics like "What are my projected sales 
over the next 24 months?" or "How is my business doing 
compared to others in this industry?". Using forecasting 
algorithms, the computer can easily be made to project 
future trends based upon past performance and expected 
future trends in the market place. Adding graphics to 
these projections produces a pictoral view of future 


trends, making the data very easy to understand. The 


whole idea of making projections (modelling) is to 
enable management to set a direction for future bus- 
iness. Questions about manpower, material, and fin- 
ancial requirements can be answered in this manner. 

It is incumbent upon data processing systems to report 
this information in any easy to understand and readily 
useable form. Graphics capabilities make this require- 
ment easy to fulfill. 

Figure 5 is an example of forecasted sales in the 
form one might expect to see from conventional systems. 
The corresponding graph makes the data much more digest- 
able and easier to comprehend at a glance. 

Figure 6 is an example of trend analysis. This type 
of data answers the question about how my business is 
doing with respect to the rest of the industry. Industry 
data is available from Dunn and Bradstreet or the Sec- 
urities and Exchange Commission. A manager can place 
his company in perspective over time to see how the com-~ 
pany is performing and whether the performance is improving 
or degrading over time. 

To this point we've looked at reporting to all five 
levels of management through the use of linear graphs. A 
short mention should be given to the ease of generating 
these graphs on an HP2648. The fact is that the HP2648 


has an autoplot function imbedded in firmware within 


the terminal. The autoplot function is complete with 
a menu to describe the X and Y axes. Once the axes 
are described, the terminal will draw the graph, with 
tic marks and an optional grid. Data for the graph 
can be obtained either from the display or from the 
HP3000. With this versatility, linear graphs become 
very easy to generate. 

The next area of importance to business graphics 
is generating other types of general purpose report 
forms. One example of this type of report is a pie 
chart. Unlike linear graphs, there is no firmware 
driven menu to generate a pie chart. However, with a 
little imagination, a simple program can be written 
to accomplish this feat. Appendix 1 to this report is 
a source listing of a Fortran program which generates 
a pie chart. Going through the program, one can see 
that the terminal graphics are controlled through the 
use Of "escape sequences". The sequences are easily 
edited into a source program or data file through the 
use of the editor. This program is included here to 
demonstrate the relative ease of generating business 
graphics, and is intended to stimulate the imagination. 

Over the past few years, the data processing in- 
dustry has seen a migration of trends. From batch sys- 


tems to interactive systems; from main frame processing 


to distributed processing. The industry has also seen 

a shift in the way people think about computers. The 
computer is losing its' shroud of mystery and is becoming 
a tool to aid businessmen accomplish goals and plan for 
the future. Data reporting through graphics is a natural 
extension to these trends and opens a whole new method- 


Ology for data reporting. 
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FIGURE l 


NOV. ‘78 ABC PRODUCTION TOTAL SCHEDULE: 330 
M-DAY SCHEDULED CUM. ACTUAL CUM. OUT 

1 15 15 14 14 
2 15 30 13 32 
3 15 45 13 45 
4 15 60 12 57 
5 15 75 15 72 
6 15 90 8 80 
7 15 105 10 90 
8 15 120 8 98 
9 15 135 10 108 

10 15 150 5 113 

41 15 165 14 127 

12 15 180 16 143 

13 15 195 8 151 

14 L5 210 

15 15 225 

16 15 240 

17 15 255 

18 15 270 

19 15 285 

20 15 300 

21 15 315 


22 15 330 
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QUANTITY 


360 
330 
306 
270 
240 
218 
180 
150 
120 

99 

60 
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FIGURE 2 


1978 ABC PRODUCTION TOTAL SCHEDULE: 3960 
MONTH SCHEDULED CUM. ACTUAL CUM. OUT 
1 330 330 325 325 
2 330 660 340 665 
3 330 990 298 963 
4 330 1320 308 1271 
5 330 1650 240 1511 
6 330 1980 290 1801 
7 330 2310 270 2071 
8 330 2640 310 2381 
9 330 2970 288 2669 
10 330 3300 
11 330 3630 
12 330 3960 
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STANDARD COST PER UNIT: 


STANDARD TIME PER UNIT: 


MONTH 


SCHEDULED ACTUAL 


OUTPUT 


330 
330 
330 
330 
330 
330 
330 
330 
330 
330 
330 
330 


FIGURE 3 


$200.00 

7.5 HOURS 
STD. 

TIME 

OUTPUT APPLIED 

325 2475 
340 2475 
298 2475 
308 2475 
240 2475 
290 2475 
270 2475 
310 2475 
288 2475 
2475 
2475 
2475 


ACTUAL 


TIME 


APPLIED 


2480 
2510 
2540 
2540 
2470 
2462 
2470 
2520 
2536 


STD. 


> 
OUT 


66000 
66000 
66000 
66000 
66000 
66000 
66000 
66000 
66000 
66000 
66000 
66000 


ACTUAL 


OUT 


65000 
68000 
599600 
61600 
48000 
598000 
54000 
62000 
57600 


STD. 


HOUR 


26.67 
26.67 
26.67 
26.67 
26.67 
26.67 
26.67 
26.67 
26.67 
26.67 
26.67 
26.67 


ACTUAL 


$/ 


HOUR 


26.2 
27.1 
23.5 
24.3 
19.4 
23.6 
21.9 
24.6 
22.7 
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DOLLARS EARNED 
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FIGURE 4 


ABC EFFICIENCY 


HOURS 


EXPENDED 


104 
112 
108 
102 
112 
88 
80 
88 
88 
48 
104 
108 
72 


HOURS 


EARNED 


105 
135 
98 
90 
112 
60 
75 
60 
75 
38 
105 
120 
60 


% 


EFFICIENCY 


100.9 
120.5 
90.7 
88.2 
100.0 
68.2 
93.8 
68.2 
85.2 
79.2 
100.9 
J11.1 
83.3 


MOVING 
AVERAGE 


100.9 
111.1 
101.2 
100.4 
100.3 
95.8 
95.6 
92.6 
91.8 
91.2 
92.2 
94.0 
93.3 
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FIGURE 5 


FORECASTED SALES AS A FUNCTION OF INVENTORY 


YEAR SALES INVENTORY 
1973 50,000 22,000 
1974 100,000 24,000 
1975 150,000 26,000 
1976 200,000 28,000 
1977 250,000 30,000 
1978 300,000 32,000 
1979 350,000 34,000 
1980 400,000 36,000 
1981 450,000 38,000 
1982 500,000 40,000 
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FIGURE 6 


TREND ANALYSIS 


Sales as a % Return 
of 1965 Current on 
Sales Ratio Net Worth 


ABC INDUSTRY ABC INDUSTRY ABC INDUSTRY 


1965 


100 100 2.60 2.40 18.0 15.0 
1966 103 100 2.59 2.44 18.0 15.0 
1967 106 101 229) 2.40 17.8 14.0 
1968 106. 100 2.995 2.45 17.7 14.9 
1967 109 101 2.57 2.41 17.7 13.9 
1970 112 103 2.61 2.38 17.7 14.9 
1971 lil 105 2609 2.42 17.8 13.9 
1972 113 108 2.54 2.38 17.7 14.5 
1973 116 110 2.52 2352 17.9 1360 
1974 119 lil 2.41 2.45 17.9 14.5 
1975 116 113 2.36 2.45 Loak 14.1 
1976 114 114 2.30 2.50 12.0 L522 
1977 
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HP See 
GRAPHICS DOLLAR DISTRIBUTION 


34.75% COST OF GOODS SOLD 






16.74% GENERAL AND ADMIN. 


12.96% NET INCOME 
12.13% DEPRECIATION 


18.59% MISCELLANEQUS 12.98% TAXES 


MON, OQCT se, 19°5, 3:54 PM 
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APPEND IM 4. 


L. 1/504 
4 $CONTROL USLINIT§ 
2 PROGRAM PIES 
3 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCOCCCCCCCCCCCCCCCCCCCCCE 
4 CCCCC§ 
S CCCE 
& C THIS PROGRAM GENERATES A PIE CHART FROM DEFAULT DATA§& 
7 C HARDCODED IN THE PROGRAM, OR FROM DATA INPUT FROM THES 
8 C OPERATOR?S TERMINAL.§ 
9 C& 
40 C WRITTEN: OCTOBER, 1978% 
i4 C DEVELOPED FOR SSR?S CONTRIBUTION TO THES 
i2 C HP3000 USER’S GROUP IN DENVER, COLORADO.§& 
13 Ch 
44 C PAUL COOPER§% 
iS C SYSTEMS ENGINEER 
16 C HEWLETT PACKARD COMPANY§% 
47 C TULSA, OKLAHOMA% 
is C (918) 665-3300§ 
i? C 
290 CCCCCCCCCCCCCCCCCCCCCCCCCCECCCCOCCCCCCCCCCCCCCCCCCCCCCCCCCCCCE 
24 SYSTEM INTRINSIC DATELINES 
22 CHARACTERXS HP ,GR& 
23 CHARACTERX2 TYES,TBLKi§¢ 
24 CHARACTERK2O LAB(141>§& 
2S DIMENSION IDUMY(10,4141)06 
2b CHARACTERK27 DATE§ 
27 DIMENSION NUMCHARS (414) ,POSLAB(141)4& 
28 DIMENSION VALUES(14),ANGLEC14) ,IBLK2(4) ,PERCT(C119§% 
2? CHARACTERXS CLEAR ,SIZE1i ,SIZE24 
30 CHARACTERK4 INIT,GRIXON,GRYXOF ,ALPOF% 
Si CHARACTERXS COMP§ 
32 REAL THETA,RADS 
33 EQUIVALENCE CIDUMY,LAB)§% 
34 EQUIVALENCE (CIBLK1,IBLK2)§% 
35 CCCh 
36 C BEGIN NOW TO INITIALIZE CHARACTER STRINGS AND VARIABLES.§& 
37 C& 
38 HP=" HP3S000 "§& 
39 GR="GRAPHICS"§& 
40 ALPOF="BXdF"@ 
44 IBLKi=" "G% 
42 LABC4)="DOLLAR DISTRIBUTION "% 
43 LAR(C2)="COST OF GOODS SOLD "§ 
44 LAB(3>="GENERAL AND ADMIN. "& 
4S LARC 4)="DEPRECIATION "G 
46 LAR(S>="MISCELLANEOUS "G 
47 LAB(C6)="TAXES "th 
48 LABC7)="NET INCOME "¢ 
49 LAB(S)=" "Ge 
50 LABC9)=" A-19.25 "& 


LS4/41006 
Si 
S2 
S3 
S4 
5S 
56 
57 
S38 
S9 
40 
& 4 
62 
63 
64 
65 
bb 
&7 
69 
69 
70 
74 
72 
73 
74 
75 
76 
77 
78 
79 
80 
84 
82 
83 
84 
85 
86 
87 
88 
89 
90 
94 
92 
93 
94 
95 
96 
97 
98 
99 

400 
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LAB(i0)=" "e 
LAB(i4)=" ne 
VALUES (4)=2240.6 
VALUES (2)=768.6 
VALUES (3)=370.6 
VALUES (4) =268.& 

VALUES (5) =234,¢ 
VALUES (6)=285.6 
VALUES (7)=285.6 
VALUES(8)=0.% 
VALUES (9)=0.6 
VALUES (40)=0.6 
VALUES (44)=0.¢ 
CLEAR="BxkdaZ"G 
INIT="6.kmR"G 
COMP="RkM3ZA"G 
SIZEL="EkMiM"G 
SIZE2="EXmM2M"G 
GRTXON="5.kdS"¢ 
GRTXOF="—xdT" 

CCC 

CE 

A THE NEXT TWO VARIABLES ARE THE X AND Y CENTER OF THE PIEG 

C 
IXCTR=3606 
LYCTR=180G 
RAD=130.& 

RRAD=140.¢ 
INUM=66 

CCCS 

C INITIALIZE TERMINAL AND SET COMPLIMENT MODE.& 

C 


WRITE(6,4) CLEAR, INIT ,COMP& 
4 FORMAT (4X, 3(AS))G 


CCCG 

C PROMPT OPERATOR FOR VALUE OVERRIDES 

C& 
WRITE(6,24)% 

24 FORMAT(iX, "VALUES FOR SALES, COSTS, ETC. WILL BE DEFAULTED”) 
WRITECS, 2296 

22 FORMAT(4X, "DO YOU WANT TO OVERRIDE THESE DEFAULTS?2")& 
READ(S, 23) 1YESG 


23 FORMAT (A2)& 

IF(LYES.NE."YE")GO TO 256 
CCCG 
C IF WE*RE HERE WE NEED NEW LABELS FOR THE PIE CHARTG 
C AS WELL AS NEW NUMBERS FOR THE SUBPARTS (PIECES).& 
Ck 

DISPLAY "INPUT THE LABELS PROMPTED FOR: "% 

DO 49 1=41,446 


Lidi/is0§% 


104 
402 
103 
104 
405 
406 
107 
i108 
109 
110 
iii 
ii2 
1413 
444 
115 
446 
1417 
118 
449 
420 
124i 
122 
123 
124 
125 
126 
427 
128 
129 
130 
131 
132 
133 
134 
435 
436 
437 
138 
139 
440 
144 
142 
143 
144 
145 
146 
147 
148 
449 
1450 
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49 
56 
91 


90 
53 


Si4 


52 
60 


61 


CCC 


LAB(I)=" ne 

VALUES (1)=0.4 

FORMAT (A20)& 

DISPLAY "INPUT NUMBER OF PIECES IN WHOLE"G 
DISPLAY "(NOT MORE THAN 410) "& 

READ(S, kK) INUMG 

IFCINUM.LE.40)GO TO 90% 

DISPLAY "GIMME A BREAK! THE NUMBER CAN’T BE MORE THAN 10"% 
GO TO 946 

WRITE(6, 53) 

FORMAT(" INPUT TITLE FOR PIE CHART: ")& 
READ(S ,S0)LABC4)G 

DO 60 I=2, INUM+4G 

JJ=1-4& 

WRITE(6 , 54) TT 

FORMAT(/," INPUT CHARACTER STRING FOR LABEL",I3,": ")& 
READ(S,SO)LAB(IDS 

WRITE(S,S2)II& 

FORMAT(/," INPUT VALUE FOR LABEL",13,": ")& 
READ(S,X)VALUES(1)§ 

CONTINUEG 

DO 64 1=2, INUM+4G 

VALUES (4)=VALUES (4 )+VALUES(1)& 


C FIND OUT THE # OF CHARACTERS IN EACH LABELG 


Ch 


2% 


409 


1410 


CCCE 


DO 440 T=4,446 

ICNT=0% 

DO 409 J=4,40G 

IF CIDUMY(J,1).EQ. IBLK2(4) ICNT=46 
IFC ICNT.EQ.0)GO TO 409% 
NUMCHARS(1)=J-46 

GO TO 41406 

CONTINUES 

NUMCHARS(1)=40& 

CONTINUES 


C COMPUTE THE ANGLES FOR THE PIE CUTS HERE.§ 
C THE FORMULA IS THE RATIO X IS TO.360 AS PART IS TO TOTAL.§& 


Ch 


28 


CCCE 
C DRAW THE CIRCLE USING POLAR COORDINATES!¢ 


C% 


ANGLE (4)=0.4 

DO 28 I=2, INUM+4G 

ANGLE (1)=(360*VALUES (1) )/VALUES (4) +ANGLE (I-4)& 
POSLAB(I)=( (ANGLE (1)—-ANGLE (I-41) )/2) +ANGLE(I-41)& 
PERCT(1)=(VALUES(1)*100)/VALUES(4)& 

CONTINUES 


DISPLAY " RhEI"S 
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iS) 
iS2 
153 
154 
155 
456 
157 
158 
i59 
160 
164 
162 
163 
164 
165 
166 
167 
168 
169 
170 
174 
172 
173 
174 
175 
176 
477 
178 
i79 
180 
184 
i82 
183 
184 
185 
i86 
187 
188 
189? 
490 
194 
192 
493 
494 
195 
496 
197 
198 
199 
200 


WRITE(6,2)& 
2 FORMATCAX, "EXpa")g 
DO 4 I=0,360,5% 
THETA=1/57 2957796 
IX=IXCTR+RADKCOS (THETA) & 
LY=LYCTR+RADKASIN( THETA) S 
WRITE(6,3)1X,1Y% 
3 FORMAT (4H+,14,4X,14," "0G 
4 CONTINUES 

CCCE 

Ck 

C COMPUTE AND DRAW THE PIE CUTS FOR THE VALUESG 

Ch 
DO 35 I=4,INUMG 
THETA=ANGLE (1)/57. 295779 
IX=IXCTR+RADKCOS( THETA) & 
LY=LYCTR+RADKSIN( THETA) & 

C& 

C DRAW THE PIE CUTS 

Cy : 
WRITE (6,34) IXCTR,LYCTR,IX,1YG 

BA FORMAT(4X, "&kpa",14,","14," ",14,",",14, "Z")G 

35 CONTINUES 


CCCE 
C DRAW LABELSG 
C§ 
WRITES, 204)GRTXONG 
DO 200 T=2, INUM+4¢ 
THETA=POSLAB(1)/S7.2957796 
IX=1IXCTR+RRADKCOS( THETA) SG 
LY=LYCTR+RRADKSIN( THETA) & 
CCCG 
C POSITION THE PENG 
Ck 


WRITE(6,203)1X,1Y& 
IF (POSLAB(I).LE.90,0R,POSLAB(I) GE. 270 WRITE(S, 204)4 
IF (POSLAB(L).GT.90.AND.POSLAB(I) .LT.270 WRITE(6, 20206 
204 FORMATCAH+, "ExXmiQ")G 
202 FORMATCAH+, "Exm7Q")% 
KK=NUMCHARS(T) 
200 WRITE(6,205)PERCT(I), CIDUMY(J,1),J=4,KK)& 
205  FORMATCAX, "EX1",FS.2,"%" 4X, 40A2)G 
204  FORMAT(AH+,A4)& 
203 FORMATCAH+, "EXpa",13,",",13, "Z")G 
CALL DATELINE (DATE) & 
LX=3606 
TY=406 
WRITE (4, 203)1X,1Y% 
WRITE(6, 207)SIZE24 
207 FORMATCA1X,AS)& 
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es Se i ee a a 


L201/LASTS 


204 
202 
203 
204 
20S 
206 
207 
208 
209 
240 
244 
242 
243 
244 
245 
246 
247 
248 
249 
/0.E.7 


208 


209 
206 


501i 


WRITE(6,208)% 
FORMAT (4H+, "Ekm4Q")§ 
WRITE(6, 206) DATER 
LY=339q 
WRITE(6, 203) 1X, TVG 
Jag 

KK=NUMCHARS (49% 
WRITE(S, 209) CIDUMY(I, J), T=4,KK)G 
FORMAT (4X, "El", 40A2)% 
FORMAT (4H+, "EX1" ,A27)& 
IX=64q 
WRITE(6,203)1X,1YG 
WRITES, 304 )HPG 
WRITE(6, 304) GRE 

FORMAT (4H+, "EX1",AB,/)& 
WRITECG, 204) GRTXOFS 
DISPLAY " EhEXdF°G 
STOPG 

ENDG 
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EXPERIENCES WITH THE 
MANUFACTURING PACKAGE MFG/3000 


I. Introduction 

MFG/3000 is a collection of three software modules that form 
an integrated MRP-based manufacturing Support package. It is ori- 
ented to manufacturers who manufacture and assemble discrete parts, 
where a primary goal is to minimize inventory investment, yet main- 
tain adequate and timely supplies for production and customer orders. 
On-line use is encouraged through the use of highly simple menu and 
data entry screens on CRT terminals, although batch input is avail- 
able. 

MFG/3000 is structured on IMAGE/3000 data bases, and permits 
the use of QUERY for ad hoc and customized reports, as well as 
some emergency data base "fixing." The on-line programs utilize 
DEL/3000, thus requiring HP 264X terminals. 

The relation between the three software modules is shown in 
Figure 1. Engineering Data Control (EDC) maintains descriptive, 
cost, and planning information about all parts, and bill-of-material 
workcenter, and routing information about the Manufacturing opera-~ 
tion. In addition, engineering change information regarding future 
changes in a bill-of-material and miscellaneous remarks about a 
part or bill-of-material may be stored. The Inventory and Order 
Status (IOS) module maintains records of planned and actual in- 
yentory issues and receipts. Work and purchase orders are entered 
directly into the system. Upon request, IOS traces through the 


relevant bills to determine and allocate all needed parts for a 
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work order (which can refer to only one fabricated part). At 

this time the user can determine if all needed parts are or will 

be available. At the proper time, based on specified lead times, 
pick lists are generated. The input resulting from the actual pick 
Operation creates a reduction in inventory level and a stock ac- 
tivity record. Likewise, receipts create a historical stock activ- 
ity record. Such records can be accessed on-line and are purged 

on a periodic basis. 

Finally, the Material Requirements Planning (MRP) module is a 
planning tool to help management balance current and anticipated 
demand for a part with current and anticipated supply for the 
same part. 

HP recommends that there be at least two management positions 
associated with the implementation and operation of MFG/3000. The 
User Trainer is responsible for educating users as to the proper 
procedures for using the system, including on-line transactions, 
management policies, and use of printed reports. The System Ad- 
ministrator is responsible for the proper Operation of MFG/3000 
itself, including data base integrity and security, maintenance, 
back-up, and modifications as required. 

This paper will discuss the experiences of one of the earliest 
users of MFG/3000, first from a user point of view (Section III), 
and then from a System Administrator view point (Section IV). Per- 
ceptions gained during implementation of an order processing system 
are shared in Section V. Enhancements, potential and recommended, 


are discussed in Section VI. 
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II. System Installation 

Vetter Corporation is a manufacturer of motorcycle accessories 
and employs approximately 250 people at an Illinois facility and 
approximately 125 at a west coast California plant. It has ex- 
perienced a high growth rate over the last few years and has had 
a continuing problem relative to materials required for the pro- 
duction and support of its products. In order to solve these 
problems, a program of investigating computer systems for inven- 
tory management was begun during the summer of 1977. 

In the fall of that year, Systems Design Associates (SDA), a 
computer consulting firm, was engaged to perform a market survey 
and analysis and to make recommendations regarding feasible com- 
puter systems. Among the criteria for the system were: 

1. Reasonably powerful data base management system software 

2. On-line query capability into the data base 

3. Ability to handle multiple data bases 

4. Ability to handle up to 24 on-line CRT terminals simul- 
taneously, with at least three background batch streams 

5. Availability of adequate maintenance and vendor support 

6. Availability of a reasonably powerful MRP application 
package 

7. Capacity for future expansion 
Primarily because of the on-line data base query capability, there 
were few feasible systems to consider. 

The HP 3000 and MFG/3000 were studied during the first months 
of 1978, followed by a purchase of an HP 3000 Series II Model 6 on 


March 22. Besides MFG/3000, this system included 320K of main 
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memory, two 50 MB discs, a 600 LPM line printer, a 1600bpi tape 
Grive, the MPE-II operating system, the IMAGE data base system, 
QUERY, DEL for terminal management, and COBOL. The 3000 arrived 
on May 2 and was installed on May 10. The industry specialist 
from the Los Angeles office installed the EDC package on May 12, 
and the following week on May 19, he installed the IOS package. 

On June 9, the MRP package was installed. The system has been 

in continuous operation since that date. During the fall of 1978 
an upgrade was made to a Series III with one megabyte of main mem- 
ory and a 120 MB disc was ordered. In addition, the new operating 
system MPE-III was installed in September, 1978. A 9600 baud lease 
line connects the Illinois plant with the California computer 
facility. 

After system selection, SDA was contracted to perform facili- 
ties management and MFG/3000 administration during installation and 
until system operation stabilized and Vetter personnel could be 
properly trained. Turnover of system management was completed 
during the latter part of summer, 1978. Currently, SDA is design- 
ing and supervising the implementation of a comprehensive Order Pro- 
cessing System—including order entry, accounts receivable, warranty 


picking, shipping, and inventory allocation—which is discussed in 


Section V. 


IIIT. MFG/3000 From A User Point of View 
The EDC package is somewhat of a misnomer for production de- 
scription. It could be more accurately described as a definition 


module, and more specifically, the definitions are all defined in 
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terms of manufacturing or production criteria. It is broken down 
into three primary divisions: 

1. Part definition—Data elements directly tied to a part 
number. Structure definition, which is the relationship between 
a number of parts which describe a finished product or sub-component. 

2. Planning and control function for purchased parts as well 
as fabricated goods. 

3. Routing and work center section to describe work centers 
and activities which occur at the work centers to produce finished 
goods and sub-assemblies. 

The IOS package handles inventory, including stock locations, 
quantities on hand, and other essential elements necessary to track 
and maintain accurate inventory records. The second portion of 
this relates to orders—purchase orders and their associated vendor 
information, and work orders, which are essentially in-house pur- 
chase orders and associated pick lists and materials requisitions 
to drive the work order system. 

The MRP package is very complete, allowing multi-purpose poli- 
cies and scheduling techniques. It is a re-generative type in that 
it 1s a batch type program which is run once a week in our plant. 
It is essentially driven by the IOS and EDC packages; and if those 
two have been brought up in a complete manner, the MRP package 
simply strips data from both and produces a series of reports which 
control and schedule both in-house work orders and out-of-house 
purchases. 

Implementation from the standpoint of the users is reasonably 


defined by the structure of the System. The EDC package must be 
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brought up first and item data entered so that it may be trans- 
ferred in a batch job to IOS in order to allow the warehousing 
people to begin to work on their inventory counts. We have found 
that at our site, with the item data set complete and outstanding 
purchase orders entered on the IOS data base, the warehousing 
functions can begin by receiving the outstanding purchase orders 
and by commencing cycle counts which are provided by the system. 
This will allow purchasing people to begin to become familiar 
with entering purchase orders on the system which have been ini- 
tiated by their old manual inventory control system. 

Essentially, this allows a small step toward bringing them 
out of their old system into an automated one and reduces the 
trauma of grossly exposing them to all its facets at the same time. 
The warehousing people at this point are simply exposed to receiv- 
ing goods on the computer and cycle counts. At this point, two 
parallel lines develop—the warehousing group can do physical in- 
ventory and load the counts on the computer and verify the inven- 
tory by additional cycle counts to guarantee the accuracy of their 
data, and the person responsible for developing the EDC structure 
information can now begin to load the structure data required to 
define the assemblies and sub-assemblies required in the plant 
operation. This data is necessary prior to the development of any 
internal work order situations. At this point, the purchasing 
people have been exposed to the system and are loading their pur- 
chase orders. The receiving department is receiving goods acquired 
from those purchase orders. Incoming inspection of those goods 


may be implemented at any point in this cycle, depending on the 


A-20@ ° 8 


local needs. At the same time, the warehousing people are becoming 
familiar with the cycle counts and details of the system necessary 
to maintain their inventories. 

The final step in the process is—with the structure informa- 
tion loaded—a final review is required of the EDC information 
necessary to define inventory control and purchase part definition. 
This information relates to lot sizes, lead times, and policies, 
etc. It is extremely important that they be related to the real 
Situations in this plant and that they be applied with good inven- 
tory management goals in mind and good purchase policies. This is 
important because of the fact that the MRP program uses this item 
data in calculating inventory purchases and demand. The system 
simply emulates the buying decisions and the manufacturing deci- 
Sions which have been attached to their component part. In es- 
sence, poor purchasing information will be followed by the computer 
and implemented just as effectively by the computer as it would by 
an individual. 

If the EDC control portion has been implemented properly and 
with all due regard for economy and control and the IOS portion 
implemented with accurate inventories and outstanding purchase 
orders, the final step is to load a master schedule useable by MRP 
to create the materials requirement plan for the plant. The key 
in developing a master schedule is, of course, to weigh the needs 
of the sales forecast with the inventory and cash goals provided 
by a finance group to provide a realistic schedule within the Ccapa- 
bilities of the physical plant which the MRP program can implement 


to drive purchase order and work order requirements. 
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One final issue is that the operational departments of the 
company be structured for control and economy with the master 
schedule with its inputs from sales forecasting and finance driv- 
ing the MRP, which provides further specific direction for purchas- 
ing and production. It is necessary that the operational departments 
of the plant be structured so that a scheduling department or pro- 
duction inventory control department be intimately tied to the fore- 
casts, etc. The computer and the MFG/3000 package will take the 
master schedule demand and provide information which may be directly 
inputted into purchasing and production scheduling. Conflicts in 
the schedule and the master plan must be resolved by the scheduling, 
purchasing, and production departments. In some cases, the master 
schedule must be revised due to the inability of purchasing and 
production to accomplish the goals. On the other hand, the system 
also provides quantitative feedback to anticipate and measure ca- 
pacity limitations. These limitations, if pointed out in advance, 
may, at the option of management, be resolved to meet the master 
schedule if its requirements are paramount to these defined limi- 
tations. 

Our feeling after using the package for approximately six 
months is that it provides extremely useful and flexible tools for 
purchasing, warehousing, and production to accomplish their objec- 
tives. It provides qualitative tools for management to evaluate 
operational departments in terms of inventory value, inventory 
turns, back order analysis, shortage analysis, and materials re- 
quirements. These may be used by the operational departments to 


evaluate their own members and by management to evaluate their 
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operating departments. The MFG/3000 package is entirely materials- 
oriented, and its biggest limitation is Simply that it encompasses 
the materials portion of the manufacturing plant's operational sys- 
tem. It provides only slight support for labor and routing informa- 
tion and provides little or no Support for the financial department. 
The package may be enhanced best by further development of product 
costing, job costing for the materials area, and the development 
of a master schedule system to ease the development of master sched- 
ules and inventory control. Obviously, to encompass all the ele- 
ments of the manufacturing plant, an accounts payable package tied 
to the purchase order portion of the I0S package is desirable; and 
on the other side of the master schedule module, an order entry 
and accounts receivable package would greatly round out the whole 
system. Of course, standard accounting functions, such as general 
ledger, etc., should be provided to tie the whole system together. 
in summary, the package has been found to be extremely easy 
to use and is easily implemented by the Operational departments. 
The design is relatively simple and straight forward so that it 
solves a large number of the operational problems of the manufac- 
turing plant without embroiling the departments in embellishments 
which detract from the objective of this system—which is to in- 
crease the efficiency and operational effectiveness of the manu- 
facturing plant. 
In many MRP-oriented systems, the goal of increased efficiency 
is obscured by "bells and whistles," which reduce the effectiveness 


of the computer-oriented system. The MFG/3000 package, in a Simple, 
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straightforward approach, has addressed the materials problems of 
the manufacturing plant in a very successful manner. We strongly 
recommend that Hewlett-Packard continue with this approach and en- 
compass the above-mentioned additional areas to provide an inclus- 


ive package for the manufacturing plant. 


IV. MFG/3000 From The System Administrator Point of View 

A. Installation. As discussed in the previous section, in- 
stallation was a fairly non-traumatic process. Vetter had the ad- 
vantage of implementing first at the California plant which was in 
the process of being established and is considerably smaller than 
the Illinois plant. In addition, since the computer system was 
on-site, communications problems were not involved. Implementation 
of each package for the Illinois plant followed California installa- 
tion by about one month. Both installations pointed out the need 
for careful planning, particularly during the loading of the EDC 
data base. For the System Administrator, early establishment of 
the default values for the various data items associated with parts 
is very important. Although direct use of QUERY can be used for 
some Simple changes to large numbers of parts, such updates must 
be done extremely carefully. Later, QUERY was used indirectly for 
massive updates by using it to create a transaction file contain- 
ing all needed changes for EDCMAINT. Such a technique can also 
be used to more easily request reports pertaining to large numbers 
of parts, instead of requesting the report for each individual part 
number through EDC. For example, one can request a bill-of-material 
for all parts meeting certain criteria. It is recommended that forms 


similar to the EDC screens be designed to simplify and control initial 


data entry. 
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As is typical, most errors are discovered during system use, 
SO one can expect to detect most of the errors in EDC during the 
early months of IOS use. 

Another problem was encountered during the installation of 
the Illinois plant. Although MFG/3000 is installed by HP assum- 
ing a MGR.MFG3000 user and account, with two plants two different 
accounts are needed (each plant has its own MFG/3000 data base). 
In addition, to save disc space and CST's, we decided that only 
one copy of MFG/3000 programs would be stored for use by both 
plants. With all programs stored in one plant's accounts, the 
Other plant needs the work files, its own data base, the forms 
files, and its own copy of the JCL (or STREAM) files. These files 
are modified as follows: 

1. The PGM= parameter of the EDC3000 and 1083000 screens 
(the first screens of the modules) must be changed to a fully 
qualified program name in the "program" account. This is easily 
done through FORMAINT. 

2. All JOB user and account names must be changed to that 
of the plant. 

3. All RUN statements in JCL and those of on-line users 
must be changed to fully qualified program names. 

4. The access security on the program groups must be changed 
to ANY for execute. A similar change may have to be made in the 
account in which the programs reside. 

Adequate security between plants is maintained since file 


references default to the log-on account, and this also causes 


our recommendation that these courses be attended only by people 
who were already educated regarding computers and manufacturing, 
thus reducing the chance they would degenerate into introductory 
courses. 

We found the quality of the courses, instructors, course ma- 
terials, and documentation to be very high. Each course lasts two 
to three days, and much material of practical worth is covered. 

We had an advantage in that the implementation of each module was 
actually accomplished before the corresponding course was attended, 
but that just increased its worth to us since problems we had en- 
countered and "tuning" issues could be discussed. There was con- 
siderable lab work, although some was simply rote. There is a 
Significant advantage in having a “live" terminal in frontof each 
student to test functions as they are discussed. 

The system specialists in MFG were also (and continue to be) 
invaluable, as problems occur particular to our installation. Tele- 
phone calls average one or two a week, and we are visited at least 
once a month. This frequency is expected to diminish over the 
next half-year. 

C. Customization. Vetter purchased the object code version 
of MFG. The source code version costs considerably more and is 
not maintained by HP. Despite this, MFG offers some customization 
abilities. 

screens may be modified under certain conditions. Alternatives 
may be added to menu screens, including branching to user-written 


routines. Fields that exist in the standard MFG data base may be 


added to data entry (FMT) screens and non-key fields may be de- 
leted from those screens. The order of existing fields may not 
be changed. Fields added to the data base by the user may not 
be added to the screens. 

Data retrieval (RET) screens, for all practical purposes, 
may not be modified except to move fields (maintaining the same 
order) and to change protected fields. 

The new user may become somewhat confused by MFG's use of 
the NEXT= parameter of a DEL screen, which usually indicates the 
next screen in a sequence. In MFG it indicates the previous 
screen, and is used to "back up." 

Field editing may be changed within the different alternatives 
offered by MFG (such as alphanumeric, numeric, etc.) as long as the 
new editing is more restrictive. The size of fields may be dimin- 
ished. 

We have modified the JCL streams often, particularly with the 
MRP module. Up to 15 levels of planning are available; Vetter uses 
only seven. Since the analysis routines are performed by chained 
STREAM commands, one need only change the last STREAMs of the last 
level desired, e.g., MRP2007J, to chain instead to the last jobs 
of the MRP process (MRP2100J and MRP2400J). In addition, MRP2400J 
must be modified to turn the FILE and SORT statements for unused 
levels into comments. Finally, the FILE statements in the last 
MERGE are likewise deleted. Thus, to add another level of planning 


is a relatively simple process of removing comment indicators. 


It is difficult, if not impossible, to modify MFG off-line 
reports. QUERY has proved to be an invaluable tool in this regard. 
In addition to the technique of producing a transaction file de- 
scribed above, QUERY is extensively used directly for producing a 
multitude of periodic and ad hoc reports. Purchasers should be 
cautioned, however, not to permit any except trained technical 
personnel to use QUERY for updates. It is very easy to get the 
data base in such a state that the pointers, etc., are in very 
bad shape. Additionally, updates lock the data base for a long 
time. In general, avoid using QUERY for anything except retrieval. 

D. Security. Probably one of the weakest aspects of MFG is 
its security provisions. There are essentially four levels of 
security: the MPE account structure, file lockwords, MFG origina- 
tor numbers, and data base passwords. 

The MPE password security is of limited value since it must 
be known by large numbers of plant personnel to enable them to 
use the system. Lockwords on user programs suffer from the same 
problem, although all our System Administrator routines are so 
protected. 

Originator numbers must be entered by the MFG user before 
access to most on-line functions. Some data retrieval and report 
requests do not require originator numbers. These numbers, rang- 
ing from 0 to 99, are assigned to individuals and groups and are 
used for distributing the Transaction Register Report of EDCMAINT 
and for controlling the functions that may be performed using each 


screen. An originator may have any of three capability levels: 
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1. None 

2. Modify 

3. Add/Delete (which includes Modify) 

Although access rights are assigned through MFG by fields, 
we have found it more practical to regard the Capabilities to be 
attached to screens since to effectively use a screen, one must 
have the same capability for all fields on that screen. Any par- 
ticular originator must have Add/Delete capability for all fields 
associated with him, not just a subset. 

Originator numbers do have some limited value in protecting 
against inadvertent but unauthorized behavior, but they have almost 
no value in protecting against intentional misuse. Originator 
numbers are restricted to only 100 alternatives and are printed on 
SO many reports that acquiring one seems a very easy process. We 
have recommended to HP that the originator number be alphanumeric. 
Although we were told that we could have 100 Originators as long as 
we had only 20 variations of capabilities, we discovered that only 
20 originators are allowed, regardless of capabilities. 

The system is installed with a system administrator Originator 
number with complete capability (in fact, there are numerous origi- 
nators existing on the originally installed system which might be 
deleted). It may be best not to have any originator with such capa- 
bility, and only create it when needed. At the very least, the 


standard administrator number should be changed since it is pub- 


lished in HP documentation. 
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A major criticism of the security is the data base protection. 
Any user with the logon password and the data base password can 
easily access (and update) the data base using QUERY. Unfortunately, 
there is one master password for write access to all fields in the 
data page: This password is common to all three MFG data bases, is 
the same for all MFG installations, is not at all cryptic, and even 
worse is published in some HP literature! For the purchaser with 
dial-up capability, a major vulnerability exists with regard to 
the security of the data base. We have recommended to HP that a 


unique password be established for each installation. 


E. Production Operation. There are many batch jobs that must 
be STREAMed to maintain the system. Data entry in EDC does not 
directly update the data base, but rather appends a record to a 
transaction file which is later used by the batch job, EDCMAINT, 
to perform the updating. EDCMAINT also produces the off-line re- 

' ports. I0S0400J strips certain information from the EDC data base 
and updates part information in the IOS data base. Other batch 

jobs update the Edit Tables (which define screen field editing and 
originators), delete parts from the IOS data base, etc. In addition, 
we have created job streams for some QUERY reports. 

Most of these batch streams require exclusive access to the 
data base for correct operation. EDCMAINT is particularly tricky, 
Since it repeatedly requests and gives up exclusive access. If 
someone logs into EDC between such accesses, EDCMAINT can abort in 
the middle. It is not a big problem to restart it in the aborted 


place, but it must be done with care and is an inconvenience. In 
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general, all batch jobs are run after working hours and/or during 
lunch. There is a slight modification to the EDCMAINT jobstream 
that will prevent logons during its execution; but this poses some 
additional problems if an abort occurs for other reasons. And, 
Since the MPG programs are shared by both data bases, this pre- 
vents users of the other data base from running EDC. One then 
tries to insure that all users of MFG are logged off prior to 
STREAMing EDCMAINT. A potential solution is to create two users, 
e.g., USREDC and USRIOS, one for each module. Another simpler 
alternative is to ask users to append their name and module in 

the HELLO command, e.g., :HELLO IVANEDC, MGR.MFG3000. A :SHOWJOB 
then indicates who is logged on. Without this additional informa- 
tion, one only has the QUIET indication on the SHOWJOB as a guide. 

It was originally intended that EDCMAINT would be run only 
once a day. However, during the first few months after installa- 
tion, changes were so frequent that four runs ina day was not 
uncommon. With more users on now and a more stable data base, 
there are two EDCMAINT runs per day, at Noon and after 5:00 Dp.M.:., 
for each plant. There is a time zone difference between the two 
plants. Thus, because of the extensive nature of EDCMAINT, users 
at one plant can experience a noticeable degradation in response 
time when EDCMAINT is being run for the other plant. 

To reduce such degradation, one may remove from EDCMAINT the 
job steps which update data sets for which the System Administrator 
is certain no transactions exist. For example, Vetter does not yet 
use the workcenter or routing data sets. Clearly, such a modifi- 


cation must be done with care. 
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In addition, STREAMing 10S0400J (which updates the IOS part 
information from EDC) has been appended to the end of the EDCMAINT 
jobstream so the IOS data base is always current with the EDC data 
base. All scheduled off-line reports are then run after the com- 
pletion of EDCMAINT. 

It is very important that the System Administrator monitor 
the EDCMAINT runs since we experienced frequent aborts and erron- 
eous data entries during the first months of operation. The aborts 
were not due to program bugs, but rather to something wrong with 
the input data or data base. The JCL comments and abort messages 
are very extensive and helpful. However, it is important to in- 
sure that EDCMAINT runs to completion before permitting users to 
initiate EDC again. The Transaction Registers should be distributed 
promptly to the originators after being reviewed by the System Ad- 
Ministrator for serious or frequent errors. We tried to insure 
that all users completely understood how to interpret the Trans- 
action Register Report and that they kept all copies on file. 

In particular, during the initial months of use, the System 
Administrator should monitor the sizes of the data sets of each 
data base. This may be easily accomplished using the DBSTATS 
routine. Capacities should be adjusted so the data sets are ap- 
proximately 70% full (or less). 

Periodic DBUNLOAD and DBLOAD of a data base can also contri- 
bute to improved response times. In a multiple disc installation, 
it is preferable to place the root file on one disc and the data 


sets on the other, thus reducing disc contention. 
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F. Multi-Plant Operation. The modifications necessary to 
the JCL, etc., to maintain only one copy of the programs ina 
multi-plant environment has been discussed in Section IV.A. Three 
problems remain for the remote plant: 

1. To direct printed output to the remote line printer 

2. To be able to defer the printing of certain reports for 
the loading of special forms, for large reports, etc. 

3. To be able to view the JCL listings resulting from a 
STREAMed job to check on the occurrence and reason for an abort, etc. 

Initially, we installed a "minispooler" provided informally by 
HP. This routine solved the first problem, but not the other two. 
Understandably, frustration was high at the remote site. 

In the fall of 1978, the minispooler was replaced with the 
RSPOOL package of DataCon of Oregon, resulting in the solution of 
all three problems indicated above. 

The JCL for the remote site's MFG system must be modified in 
the following manner: 

1. Add the OUTCLASS = LP,1l,1 clause to all JOB statements. 
This specifies 1 copy and an OUTPRI of 1. 

2. After the FILE statement for the report file, a set of 
about 10 lines must be added to initiate and control the execution 
of the routine SPOOLCOM. This connects the report file to the 
remote printer, specifies the number of copies, and permits the 
report file to be held after printing. 

3. After each execution of SPOOLCOM, there must be inserted 
a set of lines which initiate and control the execution of RPOOL. 


This sets such parameters as lines/form, number of lines between 


forms, etc. 


If the OUTFENCE of the system is set to 1 or greater, the 
JCL of the remote plant will not print on the system printer, but 
will be held in the spool files. The remote plant then uses SPOOK 
to look at the JCL files for a solution to the third problem indi- 
cated above. Since SPOOK permits access only to the JCL of the 
logon account, such users do not have access to the JCL of other 
accounts. SPOOK permits the user to list the job numbers of the 
JCL currently in the spool file, which then may be used to display 
the JCL of the job. The users must periodically purge the JCL 
files in the spooler so that it does not fill. 

If the parameters of the RSPOOL and SPOOLCOM executions are 
set appropriately, the printing of a report at the remote site 
may be deferred. SPOOLCOM may then be used on-line to alter file 
specifications in order to initiate printing when ready or to 
delete a report file. 

We have experienced great satisfaction with this arrangement. 
Essentially, it grants to the remote site all the power (and then 
some) of the on-site installation. 

G. Backup. One of the most important jobs of the System Ad- 
ministrator is scheduling and supervising backup procedures. 

Vetter does a partial backup each night, with a full system 
backup once a week. Currently, the MFG data bases are not sep- 
arately backed up using the DBSTORE program, although this will 
probably be implemented shortly since restoring from the SYSDUMP 
tape is less reliable and slower. 

The transaction file of EDC provides some roll-forward capa- 


bility, since the last five transaction files are automatically 


saved. However, this requires that a copy of the data base cor- 
responding to its state prior to the EDCMAINT run be available. 
If EDCMAINT is run twice a day and backup is performed only 

once, roll forward can be done from only two or three backup 
copies, not five. However, it is possible to modify the EDCMAINT 
JCL so that more than five transaction files are saved. 

IOS automatically provides a journaling of all transactions 
which affect the data base. The documentation is very unclear as 
to how to control this capability. In summary, the logging in 
IOS is always running. The only control the user has is to which 
device the logging is directed, disc or tape. Normally, we log 
to disc. Twice a day, STARTLOG is run to dump the current con- 
tents of the disc log file to tape, which also directs any future 
log transactions to the tape. After the disc file has been dumped, 
STOPLOG is run to direct future logging to the disc. We insure 
that no one is logged into IOS during the time STOPLOG is run. 
Besides insuring that the log file is large enough to contain the 
number of transactions likely to be entered between tape dumps, 
that is all there is to it. There is a utility to display the 
current number of log entries in the file so that it can be moni- 
tored. Our volume is easily accommodated on a 1200' reel. 

At the current time, IMAGE does not provide any journaling 
capability; thus roll-forward and roll-backward are not available 
outside of the MFG facilities. 

Another backup capability may be provided by the HP 2645A 


terminals themselves if they have the tape option installed. If 


the computer system is unavailable, or data entry takes place 
over a slow speed data line, the data may be loaded off-line 
through the terminal onto a tape cassette, then dumped to MFG 

in a rapid fashion. In order to prepare for this process, store 
the MFG screens on a tape cassette, (by displaying a screen, then 
in local mode copying to tape). Later, in LOCAL mode, display 
the selected MFG data entry screen by copying from tape to the 
screen. Put the terminal in format mode using CTRL f,- Enter 
the data normally. Pressing the ENTER key will copy the unpro- 
tected fields to the tape and clear the screen. Data entry may 


then continue in a similar fashion. Conclude by releasing format 
mode using CTRL f.- 

In order to enter the stored data, log on to MFG and display 
the appropriate data entry screen. Copying a record from tape to 


the screen and then pressing ENTER will cause MFG to read the 


screen in the normal manner. 
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V. iImplementation of an Order Processing System 


SDA and Vetter are currently implementing a comprehensive 
order processing system (OPS) to interface with MFG/3000. The 
overall structure of the system is shown in Figure 2. It con- 
sists of the following elements: 

1. Part Element—To maintain descriptive and availability 
information about each part that may be sold. 

2. Dealer Element—To maintain information about each 
customer. 

3. Order Entry Element—For the entry, review, modification, 
and reporting of information about orders. 

4. Pick List Element—To produce pick lists on a selected 
basis. 

5. Shipping Element—To produce invoices and other shipping 
documents. 

6. Accounts Receivable Element—To maintain accounts re- 
celivable information relative to orders and dealers. 

7. Warranty Element—To maintain information about the 
product and the end purchasers. 

The Part Element operates much like IOS in that it strips 
relevant information from the EDC and IOS data bases and puts it 
into the OPS data base. This continues the MFG policy of main- 
taining data base separation between major functions. Because 
IMAGE permits locking only at the data base level (but see Sec- 
tion VI), separate data bases permit an acceptable response time 
in a multiple user, on-line updating environment at a cost of du- 


plication of data and increased storage requirements. 


In addition to the obvious on-line functions, there will be 
numerous reports (well over 20) provided. 

The major contribution of this system will be timely indica- 
tions of the ship date of an order through consideration of planned 
receipts of finished goods and shipping rate limitations. We ex- 
pect to be able to predict ship dates within a day's accuracy at 
the time of order acceptance. Information concerning planned re- 
ceipts will be acquired directly from the master production sched- 
ule driving MRP or from the work orders and purchase orders of IOS. 
Thus, any change in production schedules will be immediately re- 
flected in changed order ship dates. 

During this implementation, we realized that although MFG and 
IMAGE will permit the user to add data fields to the end of data 
sets, this was a dangerous practice. Future versions of MFG could 
very well expand the number and size of data fields. The addition 
of custom data fields could prevent the easy updating of MFG, re- 
quiring special programs to unload and load the data base (since 
the new HP fields would have to be "inserted" between the standard 
and the custom fields), and the custom programs would also have to 
be changed. This was another major reason that we decided to imple- 
ment a separate OPS data base. 

There are four interfaces between the two systems: 

1. Moving part and inventory information from MFG to OPS 

2. Acquiring the master production schedule (MPS) 

3. Acquiring the shop calendar 


4. Updating the inventory counts as a result of shipments 


Acquiring part information is a very easy task. The Part 
Element has produced the side benefit of insuring that the EDC 
data bases of the two plants contain the same information about 
the same part number. 

We have not yet finalized the method of acquiring the MPS. 
This is relatively difficult to acquire directly from IOS. We 
considered having each plant Manager create an EDITOR file, from 
which we would generate appropriate transactions to IOS for MRP 
to OPS. However, this seems too complicated. Our judgment now 
is to simply scan the IOS data base for work orders for finished 
goods and create corresponding allocation data records in the OPS 
data base. Since the factory works directly from these work orders, 
we would be using the best information available. This would free 
the plant manager to use the input of a MPS to IOS as a planning 
and "what if" tool. Finally, it encourages the plant managers to 
plan their production schedule out to the horizon of shipment 
planning. 

MRP generates a ship calendar which we plan to use directly 
for assigning order ship dates. In this manner, we can easily 
take into account holidays and weekends. 

Finally, since IOS provides no method (other than stock ad- 
justments) for drawing down finished goods inventory, the OPS 
System must create a transaction file of stock adjustment requests 
that a MFG batch job uses to update the inventory levels in IOS. 


In addition, OPS generates an Issued Goods Report for cross-check- 


ing IOS stock activity records. 
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All of these interfaces have been relatively simple and easy 
to implement. It appears that MFG lends itself very well to sup- 
porting user-written custom programs. The required MFG documenta- 
tion is very adequate and clear. 

We have experienced two problems with the use of DEL in this 
implementation. Since DEL does not permit field-level reads and 
writes, the entire contents of the unprotected fields must be 
transmitted, even if only a subset of the fields is desired. In 
a remote terminal environment, this tends to radically increase 
communications line load, and if the terminal is slow, response 
time can suffer. Our only current solution is careful design of 
screens. 

The other limitation appears to be in FORMAINT. The OPS em- 
ploys a few screens where there are a considerable number of en- 
hanced, unprotected fields. We have discovered that FORMAINT (and 
DEL) will accept a maximum of 1920 characters, including the ESCAPE 
sequences for the fields. Since there may be as many as 10 charac- 
ters associated with a field just for the enhancements, this limit 
can rapidly be reached. Although the 2645A terminal may support 
a form, FORMAINT may not. Our only current solution is to give 


in and reduce the number of fields. 
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VI. Potential and Recommended Enhancements 

Enhancements from the user point of view have been discussed 
in Section III. This section will focus on improvements from a 
System Administrator view. 

With the announcement of the new IMAGE with record-level lock- 
ing, we can expect the merging of the three MFG data bases into one. 
This should produce significant improvements in storage require- 
ments and some improvement in user response time (since interactive 
programs will no longer be locking the entire data base). Some op- 
erational problems (such as exclusive access aborts) may be reduced. 
The batch programs that move information from one data base to 
another will be eliminated. EDC may be converted to an on-line 
updating system. 

Because of the problems associated with MFG updating, we plan 
to maintain a Separate OPS data base, but record-level locking will 
produce very significant operating improvements in order processing. 
The impact of VIEW/3000 as a substitute for DEL is unknown at this 
time due to the lack of documentation. However, the ability to do 
field level read/write would reduce communication loads considera- 
bly. We would also like the size limit on forms to be at least 
increased, if not eliminated. A significant improvement to DEL 
would permit the selective modification of a form, without re- 
entering all the edit specifications. In addition, it would be 
nice to simply state that no edit specs existed for the entire 


form, thus skipping laborious entering of X's. 
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Although MFG provides some journaling, we would like to see 
the logging from IOS and EDC better coordinated and similar. Roll- 
back abilities would be nice. Eventually, it would be best to have 
such recovery facilities built into IMAGE so user-written programs 
could take advantage of them. 

The OPS would benefit by a better method of entering the 
Master production schedule than as a series of work orders. 

However, the two major limitations of MFG/3000 are its secur- 
ity provisions and the high number of CSTs it demands. The secur- 
ity provisions were discussed in Section IV. Despite the large 
Size of the Vetter system, it frequently runs out of CSTs, par- 
ticularly during a COBOL compile. This is because both COBOL and 
MFG make high demands on this limited resource. In a multi-plant 
environment, we have doubts that we could oerate if a copy of the 
MFG programs were required for each plant. This limitation has 
forced us to violate the generally accepted HP3000 practice of 
small routines in the implementation of the OPS, with its attend- 
ant problems of long compiles and decreased system performance. 


We expect that MFG's high use of CSTs will be alleviated in 


future updates. 
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VII. Conclusion 


Both as user and system administrator, we have found MFG/3000 
to be a well-designed, reliable, well-documented, and "friendly" 
system, with a few relatively minor limitations. Installation 
proceeded remarkably smoothly and rapidly. Users became quickly 
familiar with the system. The addition of custom systems that 
interface with MFG is straightforward. And, lest we forget, it 


also has resulted in improved plant operation and customer service. 
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FIGURE 1. MFG/3000 
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FIGURE 2. THE ORDER PROCESSING SYSTEM (OPS) 
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SPSS/HP, an acronym meaning "Statistical Package for the 
Social Sciences"/Hewlett-Packard version, encompasses a variety 
of routines whose function it is to perform statistical analysis 
of large amounts of data. Also included are easy data entry, 
selection and modification facilities. 


Development of SPSS/HP began in 1974 at DePaul University 
in Chicago, Illinois for the HP 2000 C'/F time-sharing system. 
This development was begun due to a growing need by their users 
for a meaningful statistical analysis system capable of being 
run on a small time-sharing system. The result was SPSS/HP, an 
authorized version of SPSS, the well-known package of statistical 
programs commonly used for research and instruction in the social 
sciences. 


Iwo years later, the University of Wisconsin-River Falls 
became interested in the package and converted SPSS/HP to the 
HP 3000 computer system, expanding upon the HP2000 version to 
make efficient use of HP3000 system resources. Both sites are 
continuing to improve and enhance the package. 


In designing such a system, the aim was to develop a package 
which would be familiar to experienced SPSS users but would also 
take full advantage of the time-sharing features and resources of 
the HP systems. A user who has gained experience with SPSS at 
another institution and/or involving another computer system can, 
with little effort, use the SPSS/HP package. 


SPSS/HP is a fully interactive system. All a potential user 
is required to know is the proper log on. More sophisticated 
SPSS/HP users may take advantage of HP3000 features, such as the 
STREAM facility to operate SPSS/HP in a batch mode. 


There are. four (4) major areas in statistical analysis with 
which SPSS/HP is concerned. These areas are: 


1. Data entry, 

2. Data modification, 

3. Data selection, and 
4, Statistical analysis. 


One of the more time consuming, if not tedious, tasks involved 
in statistical analysis is that of data entry. In an attempt to 
make this task less burdensome, several methods have been incor- 
porated into SPSS/HP to accomodate several possible data forms and 
methods of data entry. In the most straightforward, simplest 
method, data may be entered directly into a SPSS/HP dise file from 
a. terminal keyboard. Such an example is shown in Appendix A. 
Alternate data entry methods include reading from magnetic tape, 
punched cards, optical mark cards or existing disc files. Data 
may also be entered in several forms, such as the traditional 80 
"column' card format, BASIC data files (BASD type) or the 
traditional keyboard entry where each data element is separated 
by a comma. All these data entry options were designed to give 
the researcher flexibility in setting up his analysis. 
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Once all the necessary data has been entered, the user may 
begin to work with the data. Several facilities are included in 
SPSS/HP to allow data editing to correct erroneously entered data 
values, the modification of existing data and the creation of new 
data through standard mathematical operations. Existing data may 
be modified by performing an arithmetic operation, such as adding 
10 to all data values for one variable, or by editing values 
individually, such as adding two existing variables, or by using 
one of the several SPSS/HP functions. The functions include 
routines which will create various statistical distributions, such 
as NORMAL, CHI, T or F distributions. Also, new data items may 
be created through the use of a mathematical-type formula of the 
form 'NEWVAR=SQRT(4*VAR1)'. 


Facilities have also been included to allow the user to 
select for analysis at a given time only a subset of the entire 
data file. This selection may be done by selecting only cases 
where one of the variables involved takes on a specified value. 
For example, suppose a variable called SEX is coded to indicate 
1J=MALE respondent and 2=FEMALE respondent. In one specific 
instance, let us assume we wish to analyze only the MALE responses. 
This could be accomplished by selecting for analysis only the 
cases where the variable SEX has the value 1. Subgroups of the 
total data file may be devised in such ways. 


The last step is then the statistical analysis itself. 
SPSS/HP currently includes 15 different statistical routines. 
See Appendix A for a list and brief description of the function 
of each. Also included in Appendix A is a sample run of the 
newest statistic, ANOVAU, which performs an analysis of variance 
for designs which have an unequal number of subjects per cell. 


In developing, converting and expanding a package of this 
nature, problems do occur which may -- depending upon the method 
undertaken to correct the problem -- affect the overall design 
of the package. Three such problems encountered during the work 
on SPSS/HP for the HP3000 will be described below. Hopefully, 
this will serve a dual purpose. First, to illustrate some of 
the considerations dealt with specifically when SPSS/HP was 
developed, and secondly, these same problems and solutions may 
apply to any type of work in the area of statistics or the 
conversion of large program packages. 


One major concern an ‘interactive program package must face 
is that of execution speed. A user does not want to sit in 
front of a terminal keyboard for endless periods of time waiting 
for calculations to be performed. Ideally, the user hopes to 
press a few keys and have the answer flash on his screen. He can 
then examine the results and decide upon his next course of action. 
Iwo programming concerns contribute towards execution speed -- 
the amount of time spent reading and manipulating the data file 


to obtain the necessary information and the size of each program 
segment. 


The first factor, the amount of time necessary to read and 
manipulate the data file, is obviously best if minimized. This 
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idea has been followed in SPSS/HP where, with minor exceptions, 

the data file is never read more than once for any given statistic. 
In a few instances, this concept was not followed in the attempt 
to allow the program to determine from the data several factors 
which otherwise the user would be required to supply. One such 
example is the routine which performs an analysis of variance for 
balanced designs, ANOVA. SPSS/HP requires two passes over the 
data file in this instance. The first pass identifies the 
specifications of the design, such as the number of levels within 
each factor in the design and the number of subjects per cell in 
the design, while the second pass reads the data to perform the 
actual statistical calculations. If only one pass had been made 
over the data, the ANOVA user would have been required to supply 
the routine with the specifications of the design. By compromising 
in this instance on the number of times the data file is read, the 
use of ANOVA was simplified. 


The second factor playing a role in determining program 
execution time, the size of each program segment, proved to be 
@ double-edged sword. Again, ideally, the smaller a program 
segment, the faster execution time obtained. The computer is 
able to spend less time swapping program segments in and out of 
main memory since smaller segments force less displacement of other 
program segments already memory resident. Striving for a small 
program segment size creates another problem. The actual number 
of program segments is then increased, one large segment split into 
two smaller segments for example. The actual number of program 
segments in any one program has a finite upper limit of 63, however. 
Faced with such a problem, it appears that the only solution lies 
in a larger program segment size with the hope that execution time 
does not degrade to a substantial degree. Upon closer examination, 
however, another solution becomes apparent. While it is true each 
program may contain at most 63 program.segments, there seems to be 
an unlimited number of programs which may be linked together thru 
the concept of Process Handling. In process handling, program A, 
termed the father process, begins execution. When condition 1 
occurs, it is directed to activate program Bl for execution. 
Program Bl becomes the son process and runs to completion at which 
time program A, the father, again begins execution at the point 
following the request to activate and execute the son. This 
linkage of programs can be extended further whereby the father 
process may activate different son processes and each son may 
become a father and activate another son. By using this technique, 
response time did not differ drastically and the various segments 
within the SPSS/HP package can remain small -- yet the total 
package remains highly expandable. 


A major concern faced when dealing with any mathematical 
formula to be calculated by computer is the problem of precision. 
Currently, standard precision of six (6) digits on internal compu- 
tations is employed. Output values may often be less accurate, 
however, such as four (4) digit accuracy. Extended precision, 
type LONG in BASIC, would provide accuracy up to fourteen (1) 
digits but was not implemented for several reasons. The initial 
data is entered in standard precision. The entry of data accurate 
to. fourteen (14) digits is rather ridiculous. The need for pre- 
cision arises in the calculations required for a given statistic. 
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In this case, a statistical routine would need to read the data 
in standard precision and convert it to double precision for use 
in calculations. In an attempt to do this on a limited scale in 
routines such as REGRESSION, it was found that internal: BASIC 
system routines controlling the conversion and formatting of 
numeric output could not handle such tasks precisely. Beyond the 
kth or Sth digit, accuracy was lost which meant the conversion 
to LONG served no purpose. An alternative method would be the 
storage of all data in LONG form initially, eliminating the need 
for conversion; but this would double the storage necessary for 
all data files, an unhappy thought for. systems constrained by 
on-line disc storage. At present, it was felt that all calcu- 
lations were precise enough to delay any efforts at further 
solutions. 


The final problem encountered evolved slowly. One basic 
design goal set at DePaul University was to avoid the use of 
scratch disc files. Some programming technique, similar to using 
scratch files, was necessary, however, to handle situations in 
which data was deleted or added from an existing data file. The 
use of the original data file twice within a routine was developed 
as a solution to this problem. The original data file was assigned 
as two separate files within a given routine, for example, as 
files #1 and #2 in a BASIC program. The old information would be 
read from file #1, the addition or deletion or modification of the 
data would be made; and then the information would be printed on 
file #2. This was a nice technique for the HP2000, which can 
handle the file buffering to avoid reading on file #1 the infor- 
mation just printed on file #2. It was discovered, however, that 
the HP3000 was not designed to handle such file manipulation. 
Overlapping of the file information began to occur after a certain 
number of file reads and prints. Faced with the failure of this 
technique, the only feasible alternative was the use of scratch 
disc files, a task easier on the HP3000 than on the HP2000. 
Temporary disc files may be built and used without any user being 
aware of the existence of such files. The only restriction imposed 
by the use of scratch files is that sufficient disc space must 
exist so that a temporary file identical in size to the original 
data file may be created---a restriction which has not shown itself 
to be a hardship as of yet. 


Several enhancements of SPSS/HP have been developed in the 
past few months. The first such enhancement increased the maximum 
number of variables which may be contained in an SPSS/HP data file. 
Previous versions have had an upper limit of 108 variables, but 
this limit has now been raised to allow 500 variables. As before, 
the number of cases is limited only by the amount of available disc 
space. 


A second recent enhancement is the capability to enter variable 
labels. This feature allows each variable declared on a SPSS/HP 
data file to be given a 1 to 40 character description intended to 
explain the purpose of the variable. These variable labels may be 
added, edited, or deleted at any time. Variable labels will be 
printed by each statistical routine. In the future, it is planned 
to include value labels, which would allow up to 10 values per 
variable to be given a 1 to 20 character description. This des- 
cription would also be printed by each statistical routine. 
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The last major enhancement to SPSS/HP has been the addition 
of a new statistical routine. This routine, ANOVAU, performs a 
fixed effects factorial analysis of variance for a design in which 
there exists an unequal number of subjects per cell. ANOVAU allows 
for either a two-way or three-way analysis of variance and no 
factor within the design may contain more than 40 levels. The 
routine provides the experimentor with four (4) models with which 
he may test his hypothesis. These models are: 1) The complete 
linear model; 2) the method of fitting constants; 3) hierarchical 
analysis; and 4) the unadjusted main effects analysis. A complete 
table of cell means and variances is also printed along with the 
analysis of variance summary table. ANOVAU will also handle a 
design which may contain up to five (5) covariates. 
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APPENDIX A 


Included in the appendix is a sample run showing data entry 
from a terminal keyboard into a SPSS/HP data file. 


Also included is a table listing all the statistical routines 
currently available through SPSS/HP and a brief description of 
the function of each of these routines. 


The output produced by the newest statistical routine, ANOVAU, 


is enclosed. This serves to show the form of the statistical 
output and to illustrate the routine itself. 
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2 FUN 


SPSSHP 


SPSSHF : VERSION 4.04 5/31/78 

SFSSHF NEWS LAST CHANGEL ON 3/31/78 

WED OCT 4 1978 8:16 AM 

TYFE NEWS FOF NEW FEATURES AND KNOUN FROBLEMS IN SFSSHF. 
TYFE INSTRUCT FOR BASIC DIRECTIONS FOR USING SFESHF. 
NEXT ? CREATE FILE! DATAQ@, 3. 24. LABELED 

FILE SUCCESSFULLY CREATED - USE ‘FILE NAME!DATAGS* TO WORK 
WITH THIS NEW FILE. 

NEXT ? FILE NAYE!DATAG@ 

NEXT ? VARIABLE LIST!READs YEAR» ACTIV 

NEXT 2 N OF CASES!24 

NEXT ? READ INFUT CATA 


ENTER CATA ONE CASE AT A TIME. 


TYFE *FROMFT* OR "NOFFOMFT' TO TUFN FROMFTS ON OR OFF PESFECTI VELY. 
*STOP* WILL INTERRUFT CATA ENTRY.- 
CASE ls READ TO ACTIV 
212128 
CASE 2, READ TO ACTIV 
21222,5 
CASE 3s READ TO ACTIV 
2122.8 
CASE 4, READ TO ACTIV 
912352 
CASE S» READ TO ACTIV 
2143,7 
CASE 6s FEAD TO ACTIV 
715357 
CASE 7e FREAD TO ACTIV 
212329 
CASE 8. READ TO ACTIV 
2124.5 
CASE 9. FEAD TO ACTIV 
2124,7 
CASE 18, READ TO ACTIV 
710457 

@ 

@ 

@ 
CASE 24 READ TO ACTIV 
2722 4,2 


DATA ENTRY COMFLETED. 
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STATISTIC NAME 


CONDESCRIPTIVE 


FREQUENCIES 


BREAKDOWN 


CROSSTABS 


T-TEST 


PEARSON CORR 


SCATTERGRAM 


REGRESSION 


RESIDUAL 


ANOVA 


ANOVAU 


DISTRIBUTIONS 


SPEARMAN CORR 


T~SQUARE 


U-TEST 


FUNCTION, 
Computes ten descriptive statistics for 
interval level data, including the mean, 
variance and standard deviation. 


Computes frequency distributions for 
categorized data. Histograms may be 
requested. 


Computes descriptive statistics for sub- 
groups of cases. A one-way analysis of 
variance can also be performed. 


Computes contingency tables from cate- 
gorized data. Four non-parametric 
statistics may be requested. 


Computes the t statistic employing one 
of three user defined parameters of 
difference of means. 


Computes Pearson product-moment cor- 
relations. 


Performs bivariate regression and prints 
scatter diagrams. 


Performs multiple regression. A backward 
stepwise procedure is available. 


Performs residual analysis. Durban- 
Watson statistics and a plot of auto- 
correlation functions of residuals and 
residuals against time may be plotted. 


Performs a factorial analysis of variance 
for balanced designs. 


Performs a fixed effects factorial analy~ 
sis of variance for unbalanced designs. 


Computes frequency distribution for con- 
tinuous data. Histogram option is 
available. 

Computes Spearman's rank-order correlations. 


Computes Hotelling's T(2) statistic 


Performs Mann-Whitnet tests. 
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NEXT 7 ANOVAULIACTIV BY READs YEAR 
NEXT 2? OFTIONS!3 


NEXT 7? EXECUTE 


STATISTICAL FACKACE FOR THE SOCIAL SCIENCES - HF VERSION 4.04 
FILE : DATAQ2 
CCREATION DATE = WED, OCT 4, 


1978 68:18 AM ) 


ANALY S1E§ OF VARIANCE 


ACTIV ETULENT ACTIVISM 
BY REAL STUDENT PEADING LEVEL 
YEAR YEAR IN SCHOOL 


MEAN AND VARIANCE TABLE 


VARIABLES READ YEAR MEAN VARIANCE. 
FOR FACTOR : READ 
LEVEL 1. 0¢ ° 08 6- 500 Ae O56 
LEVEL 2. 80 80 3¢ 357 2.863 
FOR FACTOR : YEAR 
LEVEL OO 1-08 4. 333 6- 667 
LEVEL ° 28 2. 08 4.686 7. 300 
LEVEL 2 00 3- 8 4.875 6- 696 
LEVEL ° 08 4. GB 4-806 S. 202 
FOR FACTOR : READ xX YEAR 
CELL 1-20 1. 62 8. 0aa 020 
CELL 1. 80 2.00 6-500 4. 560 
CELL te 00 3- 88 6. 2590 82917 
CELL te 20 4.88 60 333 1. 333 
CELL 2.06 1. 80 3. 680 Ae 300 
CELL 2. 88 2.00 3. 333 6- 333 
CELL 2. 08 3e 08 3- 526 le 667 
CELL 2. 20 4e 00 2.5280 « 580 
GRAND MEAN = Ae 667 
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ANALYSIS OF VARIANCE : METHOD OF FITTING CONSTANTS 


SUMMARY TABLE 


FO OOOO DO DOOR ROOD SERRE DOSS EO Ee Dewees woe mmaseecuwwncecenaacucee 


SUM OF DEGREES MEAN PROB. 

SOURCE OF VARIANCE SQUARES FREEDOM ‘SQUAPES F OF F 
MAIN EFFECTS 60. 091 4 

READ 58.966 i $8966 13.62 -@20¢ 

YEAR 2. 472 3 824 019 .98S54 
TWO-WAY INTERACTIONS 10959 3 

READ X YEAR 1.959 3 e 653 e 1S -9968 
ERROR 69- 283 16 4.330 
TOTAL 1314-333 23 


NEXT 2? FINISH 


RUN ENDED 
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DATA MANAGEMENT 


Series "B" 





PRESENTATION TITLE: 


INDIVIDUAL (S) NAME (S) : 


ADDRESS : 


ABSTRACT: 


Outline 


Adopting a Transaction Processor - getting sophisti- 
cated becomes Easier 


Robin C. Wheeler 
Domtar Construction Materials 


2001 University Ave. 
Montreal, Quebec 


A. Selection of Transaction Processor 


m WN 


. Hardware Efficiency Objectives 


Organizational Objectives 
- Standards 


. Transaction Processor Selected - Overview 


(Terminal Application Processing System) 


B. Application Considerations 


1. Objective of the Application 


2. Cost/Benefit 


3. Design Overview 


C. Considerations of a Distributed Network 


1. Linking three HP300's (Montreal, Toronto, Calgary) 
2. Communications "Futures", X.25 


D. Distributed Data Bases 
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newcerr Ml packanr 


IMAGE DATA BASE DESIGN 
AND 
PERFORMANCE MEASUREMENT 


Presented To: 


HP GENERAL SYSTEMS USERS GROUP 
7th International Meeting 


October 30th - November 3rd 1978 


Denver Hilton 
Denver, Colorado 


BY 


Orland J. Larson 
IMAGE/3000 Product Manager 


General Systems Division 
HEWLETT-PACKARD COMPANY 
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OUTLINE 


INTRODUCTION 


A. 


B. 
C. 
D 


OVERVIEW 

CONCERNS OF THE DATA BASE DESIGNER 
LOGICAL DATA BASE DESIGN 

PHYSICAL DATA BASE DESIGN 


DATA BASE DESIGN METHODOLOGY 


A. 
B. 


OVERVIEW OF DESIGN AIDS 

DATA BASE DESIGN AIDS 

1. DATA BASE ENVIRONMENT 

USER FUNCTION FLOW DIAGRAM 

USER FUNCTIONS AND REQUIREMENTS 
ITEM/FUNCTION MATRIX 

DATA BASE MODEL 

DATA BASE DIRECTORY 

DETAILED TRANSACTION ANALYSIS 


NOP wh 


IDEA — A PERFORMANCE MEASUREMENT TOOL 


IanmMOO wp 


OVERVIEW OF IDEA 

REQUIREMENTS 

OPERATION 

SAMPLE SCRIPT CREATION 

SAMPLE OUTPUT OF IDEA RUN 

GRAPHS GENERATED FROM IDEA RESULTS 
DISADVANTAGES OF PERFORMANCE MEASUREMENT 
ADVANTAGES OF PERFORMANCE MEASUREMENT 


SUMMARY 
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ws 
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HEWLETT P| PACKARD 


CONCERNS OF THE DATA BASE DESIGNER 


MUST FULFILL TWO MAIN OBJECTIVES 
@ PROVIDE A STABLE DESIGN TO SATISFY NEEDS OF CURRENT AND FUTURE USERS 
@ PROVIDE COST/PERFORMANCE TRADEOFF INFORMATION TO MANAGEMENT 


CHANGEABILITY OF USER REQUIREMENTS 

@ OUTPUT FORMATS (RAPIDLY) 

© ‘POLICIES (MODERATELY) 

@ MANUAL PROCEDURES AND INPUT REQUIREMENTS (SLOWLY) 


COMPLEXITY OF INTERACTIONS 
e DATA PEOPLE MACHINES PROCEDURES 


DATA INTEGRITY 
@ MAKING “ALL DATA” AVAILABLE TO “ALL APPROPRIATE USERS” 


FLEXIBILITY 
@ CHANGING STRUCTURE WITH MINIMUM IMPACT ON EXISTING USERS 
® DATA INDEPENDENCE 


LACK OF A DATA BASE DESIGN METHODOLOGY 


LACK OF PERFORMANCE. MEASUREMENT TOOLS 
@ THROUGHPUT ESTIMATES 
@ RESPONSE TIME ESTIMATES 
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LOGICAL DATA BASE DESIGN 


> igloo THE BUSINESS ENVIRONMENT 
CURRENT AND FUTURE INFORMATION REQUIREMENTS 
@ OVERALL OPERATIONAL PLANS AND POLICIES 
e ANALYSIS OF FUNCTIONS AND INTERACTIONS (INTERVIEWS) 
— TOP MANAGEMENT VIEW 
— FUNCTIONAL MANAGEMENT VIEW 
— OPERATIONAL PERSONNEL VIEW 


» IDENTIFICATION OF DATA ELEMENTS 
® DATA ELEMENTS USED BY EACH FUNCTION 
— DEFINITION 
— SIZE AND DATA TYPE 
— VALUES 
— SECURITY SPECIFICATIONS 
® DATA ELEMENTS SHARED BETWEEN FUNCTIONS 


» IDENTIFICATION OF LOGICAL DESIGN COMPONENTS 
— KEYS 
— ATTRIBUTES 
— RELATIONSHIPS 


98°CO-d 


HEWLETT D PACKARD 


PHYSICAL DATA BASE DESIGN 
INVOLVES THE TECHNICAL ENVIRONMENT 


PROVIDES STRUCTURES AND ACCESS METHODS NECCESSARY 
TO IMPLEMENT THE LOGICAL DATA BASE DESIGN 


CONCERNED WITH: 

CAPABILITIES AND LIMITATIONS OF A SPECIFIC DBMS 
COMPUTER HARDWARE UTILIZED 

USER REQUIREMENTS OF EACH APPLICATION 
PERFORMANCE REQUIREMENTS OF EACH APPLICATION 
PERFORMANCE MEASUREMENT 

BACKUP AND RECOVERY PROCEDURES 

DATA BASE IMPLEMENTATION 

DATA BASE MONITORING 

SECURITY 


DATA BASE DESIGN DECISIONS 
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PRELIMINARY INVESTIGATIONS 
STRUCTURE - FUNCTIONS - OBJECTIVES 
OF THE COMPANY 


BUSINESS 
FUNCTIONS 


Services Provided 
Products Manufactured 


ORGANIZATIONAL 
STRUCTURE 








OBJECTIVES 


Reduce Costs 
Increase Business 
Make A Profit 
improve Services 
New Products 


DESIGN AID #2 
FUNCTION/ACTIVITY/FLOW DIAGRAM 


ADD AND UPDATE <a READ ONLY 
USERS USERS 


HHT AR 


—— 


TRANSACTIONS REPORTS 


BATCH 
USERS 
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DATA BASE DESIGN AIDS OVERVIEW 


DESIGN AID #1 
COMPUTER/DATA BASE ENVIRONMENT 








HARDWARE 
CONFIGURATION 


DESIGN AID #3 
USER FUNCTIONS AND REQUIREMENTS 


DATA BASE 
APPLICATION 
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DATA BASE DESIGN AIDS OVERVIEW 


DESIGN AID #4 DESIGN AID #5 
ITEM/FUNCTION MATRIX DATA BASE WODEL 
FUNCTIONS 


ITEMS TYPE/ | SEARCH | SORT veoaTe| / 
SIZE ITEM ITEM | FREQ. 





\Z 


(ADDITIONAL DATA USAGE STATISTICS MAY 
BE APPROPRIATE) 


DESIGN AID #6 DESIGN AID #7 
DATA BASE DIRECTORY DETAILED ACTIVITY ANALYSIS AGAINST THE DATA BASE 


TYPE/ TIME | NO. 
ITEMS SECURITY! KEY sont| Pic ‘Pic ca DESC. | USER] TRANS] NO. TO /O DB [OPEN| SET [CALL] KEY[ARG 
iD TERMS | ENTER] CHAR] NAME]MODEI! NAME 





DESIGN AID #1 
DATA BASE ENVIRONMENT 


HARDWARE ENVIRONMENT 








COMPANY NAME: —s—SS—SC COMPUTER _§=————C MODEL = 
TYPE OF BUSINESS: ————S—CsSC<CSsi‘<CsésS< ME MORRY'SZEE 
ADDRESS: DISCS SCPC 
DATA BASE ADMINISTRATOR: ________—s «‘TAPES_———Cé@Ci&PST. 
TELEPHONE NUMBER: ____———s—SCS<S SINTERS = CNP. 
NO. TERMINALS ___.- MAKE, MODEL 
& BAUD RATE 





MAJOR ACTIVITIES OR APPLICATIONS USERS | USERS PRIORITY 





NO. NO. NO. NO. ADD | SUBSYS. 
BATCH | ONLINE | READ ONLY | & UPDATE | OR LANG. 





DESIGN AID #1 
DATA BASE ENVIRONMENT 


COMPANY NAME: HC ME I DGETS 
TYPE OF BUSINESS: W.EO0GET prstR3 Butok_ 
ADDRESS: _CUPvmERTINO, CARLIE. 

DATA BASE ADMINISTRATOR: _C_J. 4 ARSod/ 


TELEPHONE NUMBER: _4°8) 253- 1a34 





HARDWARE ENVIRONMENT 
COMPUTER _HP 3000 Sertes MODEL __ 3 
MEMORY SIZE 8/2 KB 
piscs (2) 7720 capacity SOB EA, 
TAPES (2) 7970 so ppl. _ J600 __ 
PRINTERS _301334 £LPM._600 


NO. TERMINALS __4& | MAKE, MODEL 
& BAUD oe whee? 9 aac 


NO. NO. NO. NO. ADD | SUBSYS. 
BATCH | ONLINE | READ ONLY | & UPDATE | OR LANG. 
MAJOR ACTIVITIES OR APPLICATIONS USERS | USERS USERS USERS USED PRIORITY 


ORDER PROCESSING 


INVENTORY COW TROL 


ACtounts RECEIVABLE 


RCCOunrs PAY ABLE 
PAYROLL 
PERS ONWEL / ADMIN. 


COBOL PROGRAM DEV. 


8 


/ 


/ 


2 


5 3 Co Gor 
3 l 

4 a 

6 4 

6 4 

lo 


CoGolL/ 
Query 
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DESIGN AID #2 
USER FUNCTION FLOW DIAGRAM 


INDICATE, WITH SYMBOLS, THE DATA FLOW AND 
ACTIVITY AGAINST THE DATA BASE. 


DATA BASE 
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Phone 
Tw QurRFes 


ORDERS 
RICE cnancls 
re 
REoRoER REGS 
PARTS 
RECEIVED 


ea 
Pp 
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DESIGN AID #2 
USER FUNCTION FLOW DIAGRAM 


INDICATE, WITH SYMBOLS, THE DATA FLOW AND 
ACTIVITY AGAINST THE DATA BASE. 


DEPT. 
OROER ENTRY MANAGERS (4) 
hecleiea 5 =e |e tsurte rweumy] 4) REPORTS 


ACcCounTsS 
ORDER ENTRY RECEIVABLE 


CLERKS (40) BATCH) 


RECELVING 


fee ELERKS (a) 
CL 


Vewsty Packs sing 


RATA BASE 
AcCOuwrs 
PRYARBLE 
BA 

WARE HOUSE eee 
SUPERVESOR 
4) 

awe | SHIPPING 
(2 
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DESIGN AID #3 
USER FUNCTIONS AND REQUIREMENTS 


DATA BASE APPLICATION: 
OBJECTIVES: 



















USER NAME DATA BASE NO.OF | KEY INFOR- | ESTIMATED HOURLY | RESPONSE 
OR BATCH FUNCTION OR | NO. ONLINE 1/0 MATION TIME TO THRUPUT TIME 
PROGRAM ACTIVITY TERMINALS | CHAR. | IDENTIFIER | ENTER DATA | TARGET TARGET 
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DESIGN AID #3 
USER FUNCTIONS AND REQUIREMENTS 


DATA BASE APPLICATION: DER PROCESSING /INV CoMTRoL/AccCTS PA 








+ REC 
OBJECTIVES: NTER ORDERS KEEP IVvE way UuPnaten 
HANDLE PHOVE TW QUERIES Of G@Itirwe (ACCTS RECEXVABLE ) 
KEEP PRICES mIW/VIORY CURRDVYT ACCTS PAYABLE 
USER NAME DATA BASE NO. OF | KEY INFOR- ESTIMATED HOURLY | RESPONSE 
OR BATCH FUNCTION OR |] NO. ONLINE 1/0 MATION TIME TO THRUPUT TIME 
PROGRAM ACTIVITY TERMINALS | CHAR. IDENTIFIER | ENTER DATA] TARGET TARGET 
O.£ SUPER CHM ORDERS j 1/006 ORDER-WO IS-aS Secs Low VoLunm 2-S Secs 
: Com f-ID 
LER DB/ureare ORDER-A/0 = 5D secs} G0O/ HOUR _ 
OE, CLerns| A fnew lo 150 be 3 5 - 5O ses el dale {[-3 secs 
Com? -rp 
wea diane READ /uroate i too. |LTEM-Nno IS -AS sees | cow voiumy A-S secs 
RECEIVING 
POATE TEIN -NO ~ Fo secs | GO/ Heuk ra ecs 
CLERKS OT wvEwteny = loo |* sad Mencn | 173 8 
~- 5 $ece$ 
CHSUML INO ve tomP-2D 15 - YO secs | Low vorume | 2 
prt ee REPORTS / 4 ms ORDER-WO. 
SHIPPENE VERIFY PARIS ol. loo I T£77-h0 15-30 5ecs GO /HouR a-S5 secs 
CLERKS SHIPPED EACH 
AcCcCTS READ Avy . Po 
Recetas. | PRIKT SFUNE, -———— — j|ComP-rp Seis BATCH —_— 
Dw cotati io 
(f wvosces) 
T 8 ATcr ee ee 
ACCT S PRIW Comp-3D —_—_ 
PAYABLE aE ac ad 
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DESIGN AID #4 FUNCTIONS 


ITEM/FUNCTION MATRIX / / J 
Y, 
SEARCH | SORT UPDATE " 
ITEM NAME TYPE/SIZE ITEM ITEM? FREQUENCY 
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ITEM NAME 
Comp-=ZD 


Co -NAmE 
VAL 
AmMT-.D 
ORO-NO 
L™m-No 
CUR-CNT 
UAnNT-CST 
TAX 
Rec-CodDE 
PAC - CDE 


SHP- CDE 


SLS-PRC 


DOL-LD 
ORD-DTE 
REc-DTE 
ORD - AMT 
SHP- TT 


No-LTM 


ITEM/FUNCTION MATRIX 


SEARCH | SORT UPDATE 
TYPE/SIZE ITEM ITEM? FREQUENCY 


x 50 


210 
Zz 10 


x 8 
x 8 
26 
2 6 
26 
XY 
x 4 


XL 


26 


zlo 
xb 


XG 


Zz lo 


x b 


DESIGN AID #4 
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HIGH 


Hien 


HIGH 


HICH 


Tes 


HEGH 


FUNCTIONS 
A 
x/y fs /¢ 
&/s ® Lf s 
ry &/A A ae 
Wf sé ia Sy ‘8 ix 
Py AR, vs ky AO 
2 fe SS /o See 
X 
x 
A 
i" x 
Xx 
L 
xX |X 
x |x X ix 
x | X 
x X 
x |X 
x 
X 
Xx 
x 
XxX 


, - peeree 


DESIGN AID #5 
MASTER DATA SETS DATA BASE MODEL __ DEtaIt DATA SETs 
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DESIGN AID #5 
MASTER DATA SETS PATA BASE MODEL DETAIL DATA SETS 


V 


MNAME MoOoRDER 
(comp-z0) (O R0d- wo) 


.€ 


\er" / 
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DESIGN AID #6 


Data Base Directory 





PAGE _OF 
DATA BASE NAME 
DATA SET NAME rem trem |TWE E | READMWRITE ” 
~ | cc 
E MASTER | DETAIL "Vee toe pesic| security |<2|S/& DESCRIPTION 


— — So 


DATA BASE NAME 


DATA SET NAME ITEM 
MASTER DETAIL DESIG| SECURITY 


1 


2 


3 


MNAME 


MORDER 


MINV EN 


DORDER 


DITEM 





Data 


“ORDENT” 


COMP-ID 
CO-NAME 
VAL 
AMT-LD 


ORD-NO 


ITM-NO 
CUR-CNT 
UNT-CST 
TAX 
REC-CDE 
PAC-CDE 
SHP-CDE 
SLS-PRC 
DOL-LD 


COMP-ID 
ORD-NO 
ORD-DTE 
REC-DTE 
ORD-AMT 


ORD-NO 
ITM-NO 
SHP-DTE 
NO-ITM 


DESIGN AID #6 


Base Directory 


we READ/WRITE 


210 


X8 
X8 
X6 
X6 
210 


X8 
X8 
X6 


KEY 


X2 


SORT 
P/C 


$2 


PAGE 1 OF 1 


DESCRIPTION 


109 Customer Name File 


10 


10 


- 


Truncated Company Name 
Full Company Name 
Value Current Orders 
Account Receivables 


5 ORDERS OUTSTANDING 


Order Number 


INVENTORY FILE 
Item Number 

No. of Items on Hand 
Unit Cost of Item 

Total Tax on Item 
Reception by Inventory 
Packing Code 

Shipping Code 

Item Sales Price 

Item Dollar Load 


CUSTOMER’S ORDERS CHAINS 
Truncated Company Name 

Order Number 

Date Order Placed 

Date Order Received 

Amount of Order 


ITEMS CURRENTLY ON ORDER 
Order Number 

Item NoNumber 

Item Shipping Date 


Number of Items on O:ri 
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USER 


SCRIPT 
FILE 
NAME 


TRANSACTION INFORMATION 


USER NO 
TRANS | PROCS 
NO. (TERMS 


PAUSE 


) | MIN, MAX. 


a A ts 


DESIGN AID #7 


DETAILED ACTIVITY AGAINST THE DATA BASE 


(IDEA SCRIPT FILES) 
WORKSHEET 


NO. 
NO. 1/0 |STACK] STEP 
ITERATIONS ICHARS |SIZE | Ino. 


DATA 
BASE 
NAME 


TRANSACTION STEPS 


OPEN 
MODE 


DATA 
SET 
NAME 


INITIAL 
CALL | GET KEY | ARGUMENT 
TYPE | MODE} NAME} VALUE 


NO. 
OF 
GETS 


DESIGN AID #7 
DETAILED ACTIVITY AGAINST THE DATA BASE 
(IDEA SCRIPT FILES) 


3 = UNLK 


WORKSHEET 
TRANSACTION INFORMATION TRANSACTION STEPS 
| SCRIPT {USER NO '  DAUSE DATA DATA INITIAL | NO 
USER | FILE ‘TRANS PRocS +——>——— NO. 7 STACK] STEP| BASE | OPEN] SET CALL | GET KEY | ARGUMENT ae 
1 NAME {| NO. | (TERMS) | MIN. |MAX. | ITERATIONS [CHARS | SIZE es NAME | MODE | NAME | TYPE | MODE} NAME] VALUE 
OE -ClERK) CHOS' KPT | 66 1O | 3s SO SO 150 | ORDTST| | MNAME! LocK 
| 2 _ MmNAME PuT — are. Com’ 6666 — 
| 3 DorRper| Put ComP-lLDi com 6666) — 
| y Scere) past ORD-No| ORD GELE| — 
| 5 -- |JunuK | — —- = — 
wea ca 2. 25 | ¥o 50 joo | ¥y 1 lororst| )  |mrnven| Lock | — oa oe 
| si _ _- | mrnven| GeETU| 7 TM-NO| ETM7I7 | ~~ 
— | | 3 -— —-. JUNLK -_ 
~ | | 
S| | 
si Pee ae: ae | 1s 30 SO 100 4 ! |oeprst] | prtem| 4°CK : -_ 
| 2 orem |GETH | 5 [ORD-NO| ORDBRB | 5 
| 
| 
| 
{ 
| 
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Imace Data-Base Evatuative ANALyzerR 


A DATA BASE PERFORMANCE MEASUREMENT TOOL 
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OVERVIEW OF IDEA 


ESTIMATES DATA BASE: 

e LOAD TIME 

e RESPONSE TIME 

© THROUGHPUT 

PROVIDES INITIAL DESIGN FEEDBACK 

PROVIDES FUTURE CHANGE IMPACT 

INTERACTIVELY PROMPTS YOU TO CREATE SCRIPT FILES 


GENERATES OWN TEST DATA 


EXECUTES FROM A SINGLE TERMINAL OR MULTIPLE TERMINALS 


PRODUCES SUMMARY OR DETAILED REPORTS 

@ THROUGHPUT RATES 

e RESPONSE TIMES 

RESIDES IN THE HEWLETT-PACKARD CONTRIBUTED LIBRARY 


RUNS ON THE HP 3000 SERIES I, 11, AND (11 COMPUTERS 
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IDEA REQUIREMENTS 


DESIGN MUST BE COMPLETE 


DATA BASE MUST BE CREATED (EMPTY) 


UNDERSTANDING OF THE DATA BASE APPLICATION 
UNDERSTANDING OF IMAGE CALL PROCEDURES 


DETAILED ACTIVITY DETERMINED AGAINST THE DATA BASE (SCRIPT FILES) 
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DATA BASE DESIGN IMAGE DATA-BASE EVALUATIVE ANALYZER 


(IDEA/3000) 





TRANS... 
IMAGE TX 
























SCRIPT 


icen 1. PUT 
2. GET 
TRANX | | 3. UPDATE mr free 


REPORT 








~~ > 
fn. Ge 






PROGRAM 
IDEA1.PUB 





J 
| 






SAMPLE SCRIPT CREATION 


sRUN IDEA 

SELECIS (IDEA, Version 3, May 1978) 
1 = CREATE SCFIFE1 

Zz = LOAL KUN 

3 = LES! RUE. 

4 = JIMING -FUiN 

5 = KEPURI 

6 = cSLIMATE LOAD TIstk 
7 = ERASE LATA bASE 

B = LLSI SChKIPIS 

EXILT 


RECUKUD NUMBE® 1 
Q1 IRKANSACTIUS NUMBER LU<NS9 1)? 66) 
U2 NUMEER UF FRUCESSES? (10) 

U3 MINIMUM PAUSES 
04 MAXIMUM PAUSE ? 
US NUMBER UF LLTERALIUNSS 
Vo NUMBER UF l/UeCHAPO? 
U7 oITACK SIZECy fO 16n)? 


WHICH Link 1S INCURKEC] (NUNE@CR)? 


KECURD NUFFER 2 

Q1 %RAwWSACTIUN wUMBREK 66 
SITEP NUARER O01 

02 DATAeb45SE NAMECREF) = _3 
Q2 DATAP DASE NAMEChREF) =(CRDTST 

03 UPENerULE 2d) © 

V4 WALASE' NaArRES 2 

G4 UALASF! NAMES Cat. web) 

Us Gel,Grelu,Gkiu,PuL, LUCK Gr vin: LOCK) 


wHICH LINE JS LWCUR RECT (wube Cr)? Ge) 






KECORL fhittbRER 3 

Vi IRENSACTLOR GUbeck 66 

Slkt WULKERF UZ 

UL VDAlbenbok Naek (keke = ¢ ORCOTST 
ud LfAboepAsk NAN rhrerh do = GIR 
i 


. Patlnond PANES ¢ Made pee 


ey te oe tae, (C/KY 
i> 2° > ASG lui, (Ff bi pill, Lb! Te ad uri: Gul) 

ae Bene 
Ultra we he SAU ely ee 
Vie twbilsl Vabuttad SUol 20 Cthasboy 2 (CGM ett o 
walt boat fo LuCurKekod (ntareCrh 26 ale 


i 
ws 


) 


& 


ReClUru nwUlorrr 4 
Vi a eee Gal Oe eC oe OQ" 
olbkr oe 3 : 
U2 Obewmp ect aac oe Cbabsa = 4 i, Bas pe, A 
V2 %Labeorr avr weep kbner db = 

yd YASaor Ll feb es fo 


oe od 
v4 DbDAILASr. 1 wG> et Grenier 
US Gel,Gkib,uk pi, Ped, bun (oer yuan? (U1) 
U7 REY WAKE? CUcrriu, 


us InldJabl VALUELAL $Ust 20 CHAKS) 2 (CUMPO606 


WHICH LINE LS INCURKEC] (NUNE CK) XR) B-02.27 


ao 


66100035005U0000015 
66000000N0U0000N00 
66000000N0U0000000 
6600000000V0000000 
66000nN0000U0000000 
770200250040000015 
77000000004 000N000 
T7T000000N0LO00NOUN 
7T7TO000NNDDNDVOVONNOYV 
S6BN20015NN3I000NOALS 
B800000NNOVNONNNLVY 
BBO00NNONNDLVIONNDD 
B8NDd0NONNNAVONNA ANS 
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URDTST 
UKDTST 
OnNDTST 
ONDTST 


OYOTST 
QeOTST 
ORDTST 


UNC TST 
UvC TST 
UxCTCT 


SAMPLE SCRIPT FILE 


QOXACT 

01 LOCKMNAME 

O1PUT MNAME COMP-@ID 
01PUT DORDER COMP-ID 
O1PUT DITEM OKD-NO 
OOXACT 

O1LLOCKMINVEN 

O1GETUMINVEN 

01 UNLKMINVEN 

ONXACT 

O1LOCKDITEM 

O1GETUDITEM ORDeNO 
N1LUNLKDITEM 


04908009600000000000000150 
0] 090402088000 80008808000) 


01COMP6666 0001 
01COMP6666 0001 
010RD6666 0001 


0444488888 00880009800800100 
PES ISIE L ITEP lie 
O7TITM7T7 0001 
OLESHEHHNHHOF HOT HEHHEEH DDG) 
OFS SHSHHHHOOH RHO DHHEHHN G1 OO 
OL FF HHOSRHHHneeneeHhHeQ( ) 


0SOR0D888 0005 
OL SHsesaGaataeaneeeteny lg) 


SAMPLE OF IDEA OPTIONS 


sRUN IDEA 


SELECTS (IDEA, Version 3, May 1976) 
CREATE SCKIPI 

LOAD kU 

keSl pon 

TIMING KUN 

KERURT 

ESTIMATE LOAD 11Me. 

ERASE DATA BASE 

LIS1 SCRIFETS 
I 


hm 18 th te 0h te ae Oe 


] 
2 
3 
4 
> 
6 
/ 
8 
&X 


SCKIFPI FILE NAME? CORDSCRPET 


STARLING MASTER LUAD PRUCESS 
STARTING DETAIL LOAD FRUCESS 
LOADING CUMELETE 


SELECIS (IDEA, version 3, May 197%) 


1 = CREATE SCRIPT 

2 = LOAL KUN 

3 = IESI] Ftn 

4 = JIMING RUN 

5 = KEPURT 

6 = ESIIMAITE LOAD TIME 
7 = bekASE DATA BASE 

8 = Llol SCKIEFTS 

a 


SCKIPI FIL NAME? URDSCKPT 

IRANSACLICN O08 CHECKED 

TRAWNSACITOR 77 CrakCKEI 

TRANSACTION 8h CHEeECreEL 

TEol KUN OK. DU WU wAwl GB JLELEG huwty/s) 2A) 


SruotcClilduba, Verslon 3, #ay 19/6) 


) = Crtale OCkdiE! 

2 = beh. ples 

3 SF trod pore 

$9 = abate rhe, 

5 = KRekuki 

O = BOVIMAIRE LUAL Lute. 
/ => tr&éskh VAIA vaAor 

8 = LIST Stenitla 
on 


aa 
SCRIPT FILE wie SCORDSCKPT? 
14 CPUCESSRS Regi licks: 
1234>20/69U1233 
DLAKALWG JIMING Fun 
kivwD OF ade lwnG RU 
SUKIING INBALUG 
SIARLING kKEPOF1 B-92.29 


SAMPLE OF IDEA OPTIONS (Cont.) 


i 


SELECT: (IDEA, version 3, may 197b) 
CREATE SCRIP! 

LUAL RUN 

1ES1i RUN 

LIMING FON 

REFUK { 

ESTIMATE LOAD TIME 

BRKASE DATA BASE 

LISi SCKIPIS 

1 


WHICH DATA BASE? 


APPRKUX. LOAD/OBLUAD 11Mk = Vv HKS 21 MINs 


1 
2 
3 
4 
5 
6 
7 
8 
b 


m— FH 0 tt at ek at 


>< 


NUITES ‘Inis is an estimatea time 
based on 0.15 sec/PUl ana U.1 sec 
per Update per cnain 1n a4 DElALL. 
Cnain sorting times are excluded, 


SELECTS (IDEA, Version 3, May 1978) 


1 = CREATE SCkKIPI1 
ze LGAD Pui 
3 = Ikol kU 
4 = L1eluG kun 
5 = KEFURI 
6 = bolils4Ale Luau leit 
7 = ERASE LALA BASE 
B = L1Si SCRIPTS 
Ga) 
WHICH Dalh bAdE ?(GROTST) 
ERASEL 
OrbrCrerclbeeaA, Version 3, *ay ly/oa) 
QoS CUrceeda SCad bi 
24 .; Tae © 
$3 FS Jered whan 
4 = Lllebael. ron 
> = Fkeeur il 
6 = FESTIMALE LAD I kiF 
T= treAsk Vella thot! 
8 = Liol SCFIFITS 
EX1‘ 
8 
LISITines &.. 
3 


SCKIHPT FILE Wart e URDECKP] 
IRANSACILION 65 CnkCacv 
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SAMPLE IDEA OUTPUT 


Te *cO-d 


MONe OCT 160 1Y¥/de wHEAP Am SUMMARY REPORT PAGE j 
IDFA ¥.0 -ERTI (AVERAGES) 

KACTS/ NO OF RECARDING THINKeT IME TOTAL “DELAY RESPONSE CYCLE~TIME TRANSACTIONS 
PRIICESS TIMES Time (A™ (RB) TIME (C) (A*B¢C) PER HOUR 
66/ 1 24 ~ SFCe 43-1 SECS 43.9 SECS 9 SECS 44.9 SECS 80 

6b6/ 2? 2o ef SECe 4]1e2 SEUS 41.8 SECS e5 SECS 622% SECS 85 

Ao/ 1 24 oe SECe 43.8 SECS 44,3 SECS 1.0 SECS 45.% SECS 79 

66/ 4 25 on SECe 4201 SELS 42.3 SECS e6 SECS 43.9 SECS 84 

66/7 S 25 on SECS 4229 SELS 43.3 SECS e8 SECS 44.2 SECS 81 

HAS & 2d en SECe 42e2 SECS 42.6 SECS 9 SECS 43,5 SECS 83 

hes 7 en eo SECe 42e2 SELS 42.4 SECS 1.7 SECS 44.2 SECS 8] 

AO/ & 2d 09 SECe 4lef SECS 42.4 SECS e6 SECS 43.1 SECS 84 

66/ °c 25 -” SECS 42e5 SELS 43.2 SECS 9 SECS 44.3 SECS 81 

66/1 22> oN SECS 4223 “tls 42.7 SECS e8 SECS 43.6 SECS 83 

17/1 Ie on SECe 3266 SELS 32.8 SECS 9 SECS 933.8 SECS 107 

77/ ? de 0 SECe 320d SECS 33,0 SECS ~8 SECS 43.9 SECS 106 

HH, af 2? SFCE 2le% SELLS 22.0 SECS 9 SECS 23.9 SECS 157 

hay 2? au 2 SFCe 2303 SELS 23.7 SECS 1-0 SECS 24.8 SECS 145 

AVG ResSPONSFeTIMF FOR TERMINAL MIX 9 SECS 
TOTAL WUURLY THRy-PUT FOR THE MIX 1336 


cCE°TO-a 


TOTAL 
THRU- 


PUT 


TRANS 


PER 


HOUR 


5100 
4900 
4700 
4500 
4300 
4100 
3900 
3700 
3500 
3300 
3100 
2900 
2700 
2500 
2300 
2100 
1900 
1700 
1500 


1300 | 


1100 
900 
700 
500 
300 
100 


newzerr il packanD 
912K HP 3000 SERIES II 


TOTAL THROUGHPUT MACHINE DEDICATED TO TERMINALS 


RELATED TO NUMBER OF TERMINALS 





WITH COBOL COMPILES IN BACKGROUND 


15,000 TRANS/DAY 
TARGET = ———__———"" = 
y 8 HRS/DAY 


1875 TRANS/HR 


23456789 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 
NUMBER OF TERMINALS 


o nth 
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mMmMnAzoOCnmM”A 


ms-—-- 





15 


14 


13 


12 


11 


10 


HEWLETT AN PACKARD 
512K HP 3000 SERIES I 


WITH COBOL COMPILES 
IN BACKGROUND 





RESPONSE TIME RELATED TO 


NUMBER OF TERMINALS DEDICATED TERMINAL 


nRNeapepDeanP GPR @aEP aD ap GE GE» Ga» a» exe ome ee ee ee ee om ow oe oe eo ee ow om of om o@ ow == amp ap Gp a= GP ee 
FA 
P24 TARGET RESPONSE = 2.5 


--~ SECONDS OR LESS 


123456789 10 11 12 13 14 15 16 17 18 19 20 21 22°23 24 25 26 27 28 29 30 31 32 
NO. OF TERMINALS 
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DISADVANTAGES OF PERFORMANCE MEASUREMENT 


» 


DOES NOT TAKE INTO CONSIDERATION 


THE APPLICATION OVERHEAD SUCH AS: 
@ APPLICATION PROGRAM SOURCE LANGUAGE 
© DATA EDITING ROUTINES 

e NUMBER CRUNCHING 


DATA BASE IS USUALLY NOT FULLY LOADED 


DATA BASE ACTIVITY IS USUALLY “BEST GUESS” SITUATION 
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ADVANTAGES OF PERFORMANCE MEASUREMENT 


> 
» 
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NOT A SIMULATION - PERFORMS THE ACTUAL DISK 1/0 

FEASIBILITY OF DESIGN MAY BE DETERMINED WITHOUT 

WRITING APPLICATION PROGRAMS 

DEDICATED COMPUTER SYSTEM NOT REQUIRED 

AIDS IN DETERMINING HARDWARE CONFIGURATION REQUIREMENTS 
ESTIMATES “BEST CASE” THROUGHPUT AND RESPONSE TIME 

MAY BE USED TO MODEL CURRENT DATA BASE ACTIVITY AND 


THEN THE IMPACT OF FUTURE DESIGN CHANGES 
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SUMMARY 


DATA BASE DESIGNER COULD BENEFIT FROM A COMMON DATA BASE DESIGN 
METHODOLOGY 


DATA BASE DESIGNERS NEED A TOOL TO MEASURE PERFORMANCE BEFORE 
APPLICATION IMPLEMENTATION 


HEWLETT-PACKARD HAS BOTH! 


IMAGE DATA BASE DESIGN AIDS 
INTRODUCTION 


| One of the concerns of the data base designer is the lack of a 
data base design methodology. The following data base design aids have been 

developed to provide some direction and a logical approach to assist the 

mar base designer in this most important phase in the implementation of 

a data base. 


The approach taken here is by no means the only way to design a 
data base. It is simply a logical approach starting by gathering the general 
overall information about the host computer system and the data base appli- 
cations and then working down to the detail of the actual DBMS calls against 
the data base. The main benefit of using these design aids is that they force 
the designer to gather the pertinent information related to the data base 
application so intelligent design decisions can be made. 


It is assumed that the users of these design aids have a good 
understanding of IMAGE. 


DATA BASE DESIGN AIDS 


Preliminary Investigations 


Before beginning the data base design process, the data base designer 
should first become familiar with the organizational structure, business func- 
tions, and objectives of the company and the specific group for whom the data 
base is being designed. This is very important especially if this data base 
will be used by upper or functional management to assist in the day to day 
decision making process. 


Design Aid #1 - Computer/Data Base Environment 


The purpose of this design aid is to get anoverall picture of the 
environment in which the data base will be residing. This aid provides infor- 
mation on the company, the computer hardware, and the major activities or 
applications that will be using the computer system and the data base. 


Design Aid #2 - User Function Flow Diagram 


The purpose of this design aid is to identify the data base users 
and their respective functional activities relating to a specific data base. 
The forms used and the number of users invovled in each type of function are 
shown on a flow diagram. This design aid is useful because it provides an 
indication of the overall activities being applied against a data base. 
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The key point to remember here is that each arrow touching the 
side of the data base symbol represents a transaction against the data base. 
This transaction may consist of a single DBMS call or a series of DBMS calls. 
There will be an opportunity to identify these specific calls later, in 
design aid number 7, after the data base design has been established. 


Design Aid #3 - User Functions and Requirements 


The purpose of this design aid is to describe the data base func- 
tions in more detail. The objectives of the data base should be listed to 
remind the designer of what the data base is to provide. 


Each of the arrows (functions) touching the side of the data base 
symbol in design aid #2 should now be described further. This includes 
identifying each user or batch program and describing the data base function 
or activity, the number of online terminals, the number of I/0 characters 
transmitted to and from the terminals, the key information identifier (the 
major search item that a data base user will utilize to identify or locate a 
data base record, e.g., order number, part number, etc.), the estimated 
time to enter the data, the hourly throughput target, and the response time 
target. 


Design Aid #4 - Item/Function Matrix 


The primary purpose of this design aid is to identify all the items 
in the data base and then relate them to the functions described in the 
preceding design aids. 


In addition, the item type and size are included because these are 
useful later in the data base directory. Also, indicating whether the 
item is a search item (key) is important because the search item is the basis 
for a manual or automatic master data set. Furthermore, indicating that an 
item is a sort item assumes a detail data set chain will be sorted by that 
item. The update frequency of an item can be useful to identify the high 
activity items which can affect the design of the data base by possibly 
locating those high activity items together in the same data set. 


This is the last design aid before the actual] data base design 
decisions are made. Additional data usage statistics may be appropriate 
before the final design decisions are made. 


Design Aid #5 - Data Base Model 


The purpose of.this design aid is to provide a visual represen- 
tation of the data base by showing the data set relationships. This is 
where the design decisions are made! The data base designer must now 
"earn his keep" by assimilating all the information gathered in the previous 
design aids as well as drawing on prior data processing experience to come 
up with a design that satisfies the needs of the data base users. 


If there are any words of wisdom to assist the designer in 
making these important design decisions, they are, "There is no perfect 
design!". The data base designer is usually well aware of the fact that 
the needs and objectives of a company or organization within a company 
are constantly changing. 
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Design Aid #6 - Data Base Directory 


The purpose of this design aid is to provide a means of writing down 
the structure of the data base. Later, this structure can easily be trans- 
lated into the data base SCHEMA using the TEXT EDITOR. 


The information requested is self explanatory. 


Design Aid #7 - Detailed Activity Against the Data Base 


The purpose of this design aid is to indicate the detailed activity 
against the data base for the purpose of identifying the DBMS calls required 
to complete a transaction. This information alone may help the experienced 
designer to estimate the load on the system. This design aid is primarily 
used as a worksheet for a performance measurement tool called IDEA which 
is an acronym for IMAGE Database Evaluative Analyzer. 


Two versions of IDEA (Series I and Series II) which were written by 
HP System Engineers are currently available in the Contributed Library (the 
series II version will work with the Series III). A new enhanced version of 
IDEA has been made available to our field System engineers who specialize in 
performance measurement consulting. 
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10. 
11. 
12. 
13. 


14. 
15. 


NEW FEATURES AND LIMITATIONS OF 
IDEA VERSION #3 


Each transaction can reference more than 1 data base. 
Keys must be of type U or X with a maximum length of 254 bytes. 


Within any transaction, the product of NUMBER OF ITERATIONS and NUMBERS 
of PROCESSES must be less than 32768. 


IDEA permits simulation of up to 60 terminals. The actual limit may 
be less due to the number of data bases and data sets involved and 
to the system configuration. 

The maximum record size is 512 words. 


Modifying the script file must be done under the EDITOR. Remember 
to KEEP the modified file UNNUMBERED. 


TIMING RUN processes do not "give up" at the first functional failure. 
They perform "retries" designed to force success so that they may 
continue with minimal impact on performance. If, for example, a 
directed GET fails, the data set is "rewound" and a serial GET performed. 
This fails only if the data set is empty, in which case the TIMING 

RUN is terminated. 

NOTE: These "retries" are logged and appear on the REPORT. 

For each directed GET, a random number between 1 and 100 is used as the 
address of an entry to be a read. The probability that a "retry" will 
be required depends, in this case, on the capacity and fullness of the 
data set being accessed. 


The processing which handle a transaction are created with a user 
specified stack size. 


IDEA can be run remotely. 
Multiple data bases may be accessed within a single transaction. 
Key lengths can exceed 20 characters. 


Mode 2,4, and 5 "GETS" (with or without update or delete) can be 
multiple GETS. 


No longer necessary to always perform a data base load. 
The loading is about 7 times as fast. 


Data bases can be erased by IDEA. 
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20. 


21. 


22. 


23. 


24. 


25. 


26. 


2]. 


28. 


_ 


The only "files" the user has to "build" are the data bases. 
A test run can be made to check the script. 


A "firsttime" pass through the script is also performed by each process 
prior to proceeding to the timing portion of the timing run. Puts and 
deletes are bypassed during this pass. IDEA monitors this on the 

screen by displaying one of the digits 1,2,3,4,5,6,7,8,9,0 cyclically, 
and in that order, each time a newly activated process completes this 
first-time pass. It only creates and activates another one after the 
preceeding one has performed successfully. 


IDEA handles all files and data bases so that none of them are left 
lying around. If the program should abort for any reason, this wil] 
generally not be true. 


The timing processes all terminate when any one of them terminates. They 
do this without logging any more timing records. 


An impatient user can also force early termination by entering Control-Y 
at any time after the timing run has begun. The response to the Control-Y 
may be quite slow due to the resource cleanup which transpires. 


The logging file (IDEALOG) is sorted only once into the sort file ( IDEASORT)/ 
Both files have 108 byte records with a blocking factor of 7. 


The timing processes all close the input script file to release the system 
resources tied up by leaving them open. 


The timing processes append share the IDEALOG file in multi-access mode. 
This minimizes the number of resources needed to support the logging 
function. 


IDEA and the timing processes communicate via a job control word (JCW). 
Local rins are used to control access to the user's terminal, and the 
JCW when writing II. 


A local rin is also used to queue up each timing process until they 
all have been successfully activated. 


The timing process does not give up at the first functional 

failure; it performs recovery style retries suitable to the function. 
Directed gets, for example, are implemented by the generation of a 
random number between 1 and 100 which is used as the address of the 
record to be read. If this fails, for any reason, the data set 

is "rewound" and a serial get is performed. This will succeed 

unless the data set is empty, in which case the timing run is terminated. 
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Helpful Hints 


1 


It is best to run IDEA stand-alone. This permits you to obtain timing 
data not impacted by other processes. It also maximizes the probability 
that the system resources required for a given TIMING RUN will be 
avaiable. 


If you wish to test a given script with a varying number of processes, 
Start with the maximum and modify the script for lower values on 
subsequent runs. In this manner, the starting script can be used to 

LOAD the data base once so that all Subsequent runs can be performed with- 
out reloading. 


Scripts with PUTs and/or DELETEs are likely to encounter problems during 
TIMING RUNs which may lead to early termination. For PUT scripts, pro- 
blems include full data sets, duplicate masters, absence of a required 
chain head. 


For DELETE scripts, problems include empty data sets or attempting 
to delete a master with related detail entries. 


Processes are launched for each transaction in the same order as the 
transactions are defined in the script. By entering the transactions 
with the slowest cycle time (including THINK time) first, all processes 
will get into play as early as possible. This will make the resulting 
Statistics most meaningful and with a minimum number of iterations. 
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IMAGE's COMING OF AGE: Breaking free from restrictions to 


Data-Base transformations. 


F. ALFREDO REGO 


Chairman, Software Department 

Instituto de Informatica y Ciencias de Computaciin 
Universidad Francisco Marroquin 

6a. Avenida 0-28, zona 10 

Guatemala, GUATEMALA. 


ABSTRACT 

A computerized data base should reflect an organization's 
way of behaving. As real-world circumstancies change, forcing 
the organization to adopt new ways and abandon old ones, the 
data base should also adapt itself. 


Hewlett-Packard provides tools, such as DBUNLOAD and 
DBLOAD, which allow a limited set of transformations to 
IMAGE/3000 data bases. But these tools do not lend themselves 
to the easy implementation of the radical transformations that 
are sometimes necessary. The restrictions of these tools, we 
feel, are analogous to the do's and don'ts imposed on children 
by loving parents. 


Taking into consideration that children (just like computer 
users) eventually come of age and will do their own thing 
despite formidable restrictions, we have developed a software 
system called "DATABASE.UTILITY" to help IMAGE/3000 users out of 
their data-base transformation predicaments. 


"DATABASE.UTILITY" is an MPE 'group.account’ that contains 
a set of software modules designed specifically to allow a large 
selection of transformations to IMAGE/3000 data bases without 
having to mess around with magnetic tapes or schema recompilations. 
And, in good parental fashion, this system also keeps a watchful 
eye for any possible difficulties that might potentially upset 
the health, consistency :-and integrity of the "adolescent" data 
base. 
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Concurrent data-base operation and evolution, data-base 
adaptability, data-base consistency, data-base conversion, 
data-base design, data-base integrity, data-base redesign, 
data~base restructuring, data-base management systems, DBMS's, 
data-base transformation, Hewlett-Packard's IMAGE/3000 Data-Base 
Management System, root file transformation, schema changes. 


How can I be ABSOLUTELY sure that my data-base design is perfect? 
How can I GUARANTEE that I will NEVER have to change it to meet 
unexpected shifts in my organization's way of doing things? 


If I can not answer these questions to my satisfaction, then 
what type of tuning (and fine-tuning) tools do I need to 
facilitate the constant and inevitable evolution of my data base? 


What type of questions worry me about the tools I have 
currently available to me? And what type of questions linger in 
my mind as I dream of better and more effective ways to do what 
I have to do anyway? 


- Why do I have to COMPLETELY STOP the operation of my live data 
base, even when I only want to make very slight changes like 
password reassignments? Could I maintain concurrent data-base 
access while I do certain non-radical transformations or while 
I radically transform data sets that are not being currently 
accessed? ("DATABASE.UTILITY" ANSWERS: yes.) 


- Why do I have to spend (a sometimes very long) time to DBUNLOAD 
my WHOLE data base to magnetic tape before I transform my 
schema (assuming, of course, that I do not want to lose the 
live data I presently have!)? Could I skip the whole DBUNLOAD 
trip? ("DATABASE.UTILITY" ANSWERS: yes.) 


- Why do I have to spend (a sometimes even longer) time to 
DBLOAD my previous data base, even though I merely want to 
optimize the storage locations of a primary path's entries? 
Could I simply reshuffle these entries without having to think 
and worry about the consequences of having to reshuffle the 
whole data base as well? ("DATABASE.UTILITY" ANSWERS: yes.) 


- Why do I have to PURGE my entire data base, when all I want is 
to change the name of a data item? Could I simply make changes 
such as this without having to kill (and then re~issue life to) 
my data base? ("DATABASE.UTILITY" ANSWERS: yes.) 
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Why do I have to EDIT and recompile my schema, when I simply 
want to change the read/write capabilities of a user class? 
Could I dinamically do this while the data base continues to 
earn its living? ("DATABASE.UTILITY" ANSWERS: yes.) 


Why do I have to CREATE, from the newly produced root file, 
a brand-new data base, if the old one was just fine except 
for the capacity of a data set? Could I change the capacity 
of a data set without having to go through this process once 
more? (''DATABASE.UTILITY' ANSWERS: yes.) 


Why am I at the mercy of subtle schema changes that CAN cause 
very unpleasant surprises, even after my previous data base 

has apparently been successfully DBLOADed to my new data base? 
Could I have some ‘editor’ which would make sure I do not 
clobber my schema? Could I know, before I ruin anything, that 
my data-base transformation request is illegal? Could I have 

a dialogue with the system to "discuss" the possible consequen- 
ces of subtle changes in transformation requests? ("DATABASE. 
UTILITY" ANSWERS: yes.) 


Why do I have to write special application programs whenever I 
need to transform my data base in ways that are not supported 
by IMAGE/3000's transformation utilities? Could I have a 
flexible, non-procedural system that would even assemble data 
entries from bits and pieces taken from other data entries 

from the same data base, or from other data bases, or even from 
good old MPE files? Could I do data-type conversions (from 
integer to byte, from integer to double-integer, from byte to 
real, from integer to logical, from floating-point to byte with 
decimal-point suppression and decimal-place right-justification, 
etc...) if the source data type does not match the destination 
data type? ("DATABASE.UTILITY" ANSWERS: yes.) 


"DATABASE.UTILITY" is an MPE ‘'group.account’ with privileged 
capabilities assigned to it by the computer installation's system 
manager. 


All our design trade-offs have one main objective: to 


preserve data-base consistency and integrity. We strongly feel 
the same way about preserving other user's domains and, of course, 
about preserving the operating system itself: Therefore, all 
privileged instructions in "DATABASE.UTILITY" are executed in 
bracketed fashion (that is to say, the programs execute in user, 
non-privileged mode 99% of the time; whenever it is imperative 
that privileged instructions be executed, a dynamic call to the 
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GETPRIVMODE system intrinsic is made immediately BEFORE the 
privileged instruction; then, a dynamic call to the GETUSERMODE 
System intrinsic is made immediately AFTER the privileged 
instruction.) 


A good 90% of all module execution times is spent in making 
reasonably sure that the requested transformations are legal and 
will not produce unpleasant results. Complete log-on subsystems, 
analogous to MPE's, check to see that only authorized users 
access the programs. An IMAGE/3000 data base (of course!) is 
kept for all programs, users and transformations as applied to the 
various data bases in an installation. 


At the least sigh of trouble, the target data base or data 
set is purged and the old one can be salvaged. 


When necessary, the root file is appropriately "updated"; 
MPE files are created or purged as needed; data sets are re- 
organized to include or exclude structural information; data sets 
and data items are re-numbered if any intermediate elements have 
been eliminated, etc. 


The Data Base Administrator (DBA) can easily obtain an 
up-to-date picture of the transformed data base by means of 
QUERY's "FORM" command and our own "PASSES" program. "FORM" lists 
data sets, data items and paths as defined within the data base's 
structure. ''PASSES" lists passwords and user read/write classes. 


1) NON-TRANS FORMATIONAL 


ASSEMBLE: Assembles data entries ("records") for master or 

detail data sets from one or more data sets or MPE 
files. The source data sets may be mixed from several data 
bases and may be either details or masters. The source MPE 
files may be accessed sequentially or directly by key. 


The program asks all relevant questions, such as data-item 
types (integer, byte, logical, etc.), beginning byte or word 

in the source entry/record, etc. If it detects inconsistencies 
(for instance, if the source data-item type is byte and the 
target data-item type is double-integer), it explains them and 
requests instructions to perform one of several possible 
actions, depending on the particular circumstances: ignore and 
re-try? do data conversion? ... 
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2) GLOBAL DATA-BASE TRANSFORMATIONS 


3) 


COPY: Copies a data base from a source 'group.account' 
to a destination 'group.account'. The data-base 
creator MUST RELEASE the data base beforehand. 


RELEASE: Releases the root file and all MPE privileged files 
assigned to a data base, so it may be copied from 

another 'group.account' (or accessed through QUERY or other 

application programs when running from other 'group.account') 


SECURE: Reverses the effect of "RELEASE", securing the data 
base from access through other "group.account'. 


RENAME: Assigns a new name to a data base. Changes MPE 
file names as well as internally-kept IMAGE names. 


PASSES; Reports, lists, modifies, assigns, re-assigns, takes 
away, etc., maintenance passwords and read/write 
passwords and class numbers. 


PURGE: Purges the root file and all MPE files assigned to 

a data base. Loops around asking for other data 
bases to be purged, instead of ending after having purged a 
data base as "DBUTIL, PURGE" currently does. 


AUDIT: Produces a report of the usage of '"DATABASE.UTILITY" 
programs by user, program, data base, etc. 


TRANSFORMATIONS OF DETAIL DATA SETS 


NEWDTAIL: Adds new detail data sets to the data base (with the 


appropriate new data items, if needed.) 


CAPDTAIL: Modifies the capacity of a detail data set, preserving 
all current chains and making sure, in the case of a 

decrease in capacity, that the target capacity is at lease equal 

to the lowest permissible capacity for the given set's status. 
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4) 


5) 


KILLDET: Deletes a detail data set, making sure that it is 

safe to do so. It optionally dumps the entire set 
to an MPE file in the format specified by the user (or dumps 
only those data entries within the data set that meet the 
boolean specifications given by the user.) 


TRANSFORMATIONS OF MASTER DATA SETS 


NEWMASTR: Adds new automatic or manual master data sets to the 


data base (with the appropriate new data items, if 
needed.) 


CAPMASTR: Modifies the capacity of a master data set, 


preserving hashing properties for calculated access 
and chain-head structural information. Reduces synonym 
occurrences by suggesting program-calculated prime-number 
capacities in the neighborhood of the user-specified capacity. 


KILLMAST: Deletes a master data set, making sure that it is 


safe to do so and that no chains will be left hanging 
without chain heads. It optionally dumps the entire set to an 
MPE file in the format specified by the user (or dumps only 
those data entries within the data set that meet the boolean 
specifications given by the user.) 


TRANSFORMATIONS OF DATA ITEMS 


NEWITEM: Adds new items to existing data sets. 


KILLITEM: Deletes a data item from an existing data set. If 


all data-set references to a given data item have 
been deleted, the item is also deleted from the root's item 
table. 


RDEFITEM: Re-defines the type of a data item (from integer to 


byte, for instance), and does all the appropriate 
data conversions if necessary. If the new data type has a dif- 
ferent word-length count, all data sets that reference the 
given item are re-organized to reflect the new structure. 
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6) TRANSFORMATIONS OF ELEMENT REFERENCES 


7) 


NEWNAME: Assigns a new name to a data item or a data set. 


Checks non-duplicity and legality of new name. 


TRANSFORMATIONS OF ACCESS PATHS 


NEWPATH: Defines a new path connecting an existing master 
data set to an existing detail data set by means 

of an existing data item (i.e., it upgrades non-key data items 

to the status of key data items or SEARCH ITEMS.) 


CLOSPATH: Deletes a path between a master data set and a detail 
data set. (i.e., it downgrades key data-items or 
SEARCH ITEMS to the status of non-key data items.) 


SORT: Upgrades non-sort data items to the status of sort 
data items for a given path. 


UNSORT: Downgrades sort data items for a given path to the 
status of non-sort data items. 


PRIMARY: The path most frequently accessed in chained mode 


should be specified by the Data Base Administrator as 
the primary path for a detail data set. Should this state of 
affairs change, the DBA can specify that another path become 
the primary path for the detail data set by means of this program. 


PAVEPATH: Reshuffles the entries of a detail data set so that 
the entries of each chain within the primary path will be in 
contiguous storage locations (for efficiency's sake in chained 
retrieval.) 
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~~ CONCLUSIONS -- 


A) PARTICULAR: 


“DATABASE.UTILITY" worries and keeps track of all IMAGE/3000 
internal housekeeping, while the data base evolves. 


The user is, then, free to concentrate his/her energies on the 
ONLY housekeeping task that really matters to him/her: THE 
DATA BASE'S ACCURATE REFLECTION OF THE ORGANIZATION'S WAY OF 
DOING BUSINESS. 


The user can, now, specify WHAT he wants to have in his data 
base, knowing that tomorrow he can easily re-specify his 
requirements without having to fear lack of compatibility. HOW 
this is accomplished is the responsibility of 'DATABASE.UTILITY". 


B) GENERAL: 


Our research and development team has concentrated its efforts 
on helping users of Data Base Management Systems realize the 
tremendous potential of this emerging computer technology. 


In this report we mention only some of the projects that keep 
us busy and happy in the Land of Eternal Spring, Guatemala. 
Currently, we have software systems in various stages of 
development. The wide range of status is illustrated by the 
fact that some have been successfully installed at customer 
Sites after alpha, beta and gamma tests and some others have 
just been dreamed up (such as our data dictionary project.) 


To widen the scope of our activities, we would appreciate 
hearing from those researchers, developers, users and friends 
of Data-Base Management technology who share our enthusiasm. 
We will carefully examine and consider all suggestions and 
criticisms as well as any proposals for cooperation. 


We wish to express our appreciation to all our associates and 
friends who, directly or indirectly, made our software projects 
possible. In particular, we are indebted to: Jon Bale, Gabriel 
Buzzetti, Enrique Castillo, Alex Dengo, Pablo Gutierrez, Lissa 
Hanckel, Max Holzheu, Jerry Johnson, Einar Klanderud, Orly Larson, 
José Mir6én, Félix Montes, Manuel Ponciano, Clara Maria Ramirez, 
Patricia Springmuhl de Rego, Simdn Sibony, Sergio Tenenbaum, 

John R. Trudeau, Fred White, René Woc. 
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Faster witn FAST KSAM 


by 
Stephen M. Butler 
Director of Data Processing 
Paradise Valley Hospital 
National City, CA 


BACKGROUND 


Being a hospital, we maintained a manual inaex to patient numoers. The 
mecnanical device was overloaded (280,000 in a 250,000 capacity Die- 
bold), and the repair bills were worse. 


During the analysis of the HP-3000 a prototype computerized Medical 
Index using IMAGE was written; but ALPHA or NUMERIC sequence searches 
could not be used-=ewho wants a sorted chain of 280,000+ entries. A 
pnonetic search was implemented but the chain had cases of 2000+ 
entries. A generic Key capability for the phoneticebirtndate search 
mechanism was needed. 


The prototype index gave us the impetus to acquire tne 3000. As the 
conversion from a Honeywell 115 neared completion, KSAM became avail- 
able. I1t nad the capabilities needed: 


i. Multiple keyed ISAM. 
2. Generic keys. 


Wwe claim to be the GAMMA test site for KSAM=-i£ such exists. It seems 
there were updates every other week--at least we saw our SE! Finally 
there was a version of KSAM clean enough to attempt a load of tne 
260,000+ records. It took 5 days for the disk drives to survive the 
Ssnaxe out test; but one of the other systems started acting funny. Soon 
we were in the GAMMA test pnase again. After several attempts to fix 
tne bug, the SE took our test program and disappeared. (He claimed he 
wouldn’t come pack until there was a version of KSAM that would work = on 
his machine!) 


The next week he laid the update tape on our oesk: we haa become past 
masters of doing KSAM updates. The SE’s parting comment was, "That 5 
day load should be faster." "Did we get FAST KSAM?" "Can’t say; but 
don’t tell anybody else." 


The reload took 2°1/2 days. Not the 100U0% improvement expected, and 
there were more pugs. So, we wrangled a day at the lab to find out why 
a particular pug had so many tacets and why it was taking upwards of a 
month to fix a problem we felt was criticale A lot of information was 
passed in both directions, ana the lab thanked us for peing a BFTA test 
site. wished somepody had told us sooner! 
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Faster with FAST KSAM 


Tne new version of KSAM was quoted to be the pre-release version that 
would follow the MIT following 1814. That was Feb. 9, 1978. It passed 
all our tests and is now on the 1814 M.I.1. 


Following tips fron the lab, the load took 20 £4-nours. Not bad for 
250,000 records. In retrospect we are nappy to have picked KSAM, 


KREYEILE 
An understanding of tne KEYFILE will help in Knowing why the tollowing 
tips work. A close reading of the new Appendix B in the KSAM manual 
wlll be useful. 


First, the KEYFILE record size is one sector (128 words: 256 bytes). 


Tne CONLROL block is described in FIGURE 1. The number of keys per 
record is the main item of interest. 


CONTROL BLOCK (first bieck in each key file) 


Word 
0-3 Daia File Name ———— identifies data file 
associated with 
4-15 Date/Time key file 

16-17 Version/Fix 

18-19 # Records in Data File 

20-21 =B'ocks in Data File 
22 = Words in Lest Data File Block 
23 Dita File Blecking Factor 


24 Data File iecord Size 


Intrinsic Calls 
25-58 
(each a dou!e word) 
Total file access 


59-60 Key Bluck Read Counter counts, used by 
61-62 Key block Write Counter VERIFY command 
63-64 Key Block S:it Counter 





————————— specifies number of 


77 
; keys defined for file 


128 


FIGURE i, CONTROL 3LUCK Layout. Note wOrd 77, 
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Faster with FAST KSAM 


Tne KEY_DESCRIPTOR block nas one entry of 8 words for each detined 
Keye Tne detailed layout is in FIGURE 2. The most useful items right 


now are tne pointers to tne ROOT KEY ENTRY block for each of the defined 
keys. 


KEY DESCRIPTOR LUG 
bis= 01 34 78 ie ONS 


pointe; to primary ——— —————_—-+ 
key root block 






1 
2 
3 
locetion in data record —- 4 primary 
of primary key =) key 
(D=Duplicate key flag) 6 
7 
8 


pointer to Ist alternate ————_—__—__—_—____» 
key root biock 


. it ar “+ d 
location in data record ——————_——————__» Alternate 
of Ist alternate key 


13 Key } 


additional entries for up 
to 15 alternate keys 


128 


FIGUPES 2, KEY ESECRIPTOR BLOCK. Each entry cone 
sis * 8 woras. The RESERVED area is a 
to the free list chain for this 


Tne KEY_ENTRY blocks contain the Key values and pointers used to make 


KSAM do its thing. A quick look at FIGURF 3 will show that a key entry 
is composed of: 


i. Double-word relative record number of the KEY ENTRY 
block that sequentially comes before this entry. 


2. KEY value as it is in the Data Record. A slack 


byte is at the end if the key length is odd. This 
slack byte IS NOT initialized. 
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Faster with FAST KSAM 


3. Doubleeword relative record number of the data 
record in the data file. 


4. Double-word relative record number of the KEY ENTRY 
block that sequentially comes after this entry. 


[| | 


FIGURE 3, KEY ENTRY. see text for description of 
Numbered items, 


With two or more keys item 4 becomes item 1 for the next Key in that KEY 
ENTRY block, see Figure 4. Thus there is 1 more KEY ENTRY pointer. than 
the number of active Keys in that block. Since each KEY ENTRY has a 
data pointer also, the number of double word pointers can be written as 


2N + 1 
wnere N is tne number of Keys per KEY ENTRY block. 


Eacn KEY ENTRY block starts out with a double-word integer whose value 
is the relative record number of that block. Tne next wora nas a count 
of the number of active keys in this KEY ENTRY block. Subsequent 
records within the same KEY ENTRY block do not have this information. 
The key value within a KEY ENTRY block can be split across the physical 
blocks of the KEYFILE. Using FCOPY to daump tne KEYFILE with °;NOKSAM; 
OCTAL;CHAR’ options will allow a person to inspect the actual layout for 
a particular file. Thus a person could simulate conditions that would 
normally be hidden deep inside a large file. Unce you know the general 
layout you will quickly pick up tne specific pieces of information 
neeaed to navigate through the KEYFILE. 
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Faster witn FAST KSAM 


# of keys active 


ecord number 





FIGURE 4. KEY Ei TRY BLOCK. words 1 & 2 contain the 
relative record number for this block. 
word 3 contains the number of active 


Keavs. "“otice how items 4 and 1° are 
Shared bv adjacent KEY ENTRPYsS. 


we nave spent upwards of two days at a time sifting through a KEYFILE in 
tnis manner in order to pin point KSAM bugs. On one occasion a bug 
seemeaq to occur only on our 280,000 record KSAM file. My boss bet a 
milxsnake that 1 couldn’t simulate it with less than 100 records. I did 
it with seebut 1 first Knew exactly what was happening. 


FiGuRe 5 can be followed to calculate the blocking tactor (6F) tor each 
key. A specified BF is used as a minimum and is adjusted upwards to 
make full use of any remaining area in the last sector. The agefault BF 
is cnosen so that the KEY ENTRY block will span 6 sectors--1024 words 
(2048 bytes). If the KEY ENTRY block spans more than 16 sectors (2048 
words or 4096 pytes), the BF is reducea so a maximum of 16 sectors is 
us@a. 


Witn multiple keys the largest KEY ENTRY plock size is used to calculate 
the BF for all Keys. Thus all KEY ENTRY blocks occupy the same number 
ot sectors. Tnis along with the 16 sector maximum are by-products of 
requirements tor usino the KSAM extra data seqment. 
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key size in bytes 

key entry size in words 
blocking factor (number of key entries per block) 
key block size 


data file limit in records 
number of sectors per key block 
key file size in sectors 

roundup [| j= round down 





ES = L(KS + 1) /2J+4 <———— 2 words/pointer 
fewest # words that contain key entry 


BF specified? 


Y 


PF = cvon number? egy or 
Y 


BS = (ES X BF) +5 «<—————- 3 contro words + 2-word pointer 


ES= 1024 
(defauit! 


NB = [ BS/1287 


# words in sector 


BS = NS x 128 «<——_——_——_——. optimum block size 


| 


BF =f (L (BS-5) /ES J -1) /21x 2 «<———_____ adjusted BF 


—r— 


— # key entries in block 


_—- 


| oa sounded to nearest even whole # 
FL specified? a 
Y FL = 1024 (default) 


FS=(TFL/BF 1 x2)x NB 
double # of blocks foi block splitting 


FIGURE 5. Calculating blocking factor (BF) and file 
Size (FS) for one Key. 
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Assume a file with 2 keys defined as: 


KEY = B,1,53,12 
KEY = 8,54,13,20 





For Key 1: 


KS=53 
FL=1024 (defautt) 
BFH12 


Calculation of FS: 


ES= L(53+1)/2J+4 = 27+4 = 31 
BS=(31x12)+5 = 377 
NB=f 377/128 1=7 2.9 1= 3 sectors 
BS= 3x128 = 254 
*BF= Pf (L(384-5)/21 !-1)/2 1x2 
#=— (112.2 J-%) 2742 
=((12-1)/21:2 
= 5.5 Ix2 = 6x2 = 12 
FS=(11024/121x2) x2 
«(85.3 Ix2)xs 


= §16 sectors 


For Key 2: 


KS=13 
FL=1024 (defauit) 
BF=20 


ES=L(13+1)/2J+ 4 = 7+4= 11 

BS= (11x20) +5 = 225 

NB=1 225/128 1211.75 1= 2 sectors 
BS= 2x128 = 256 


*BF=F(L(256-5) /114 -1)/21x2 


=1(L22.8 J-1) /27 x2 

= (22-1) /21x2 

=f10.5 1x2 = 11x2 = 22 
FS=(11024/221x2) x2 

=((46.51x2) x2 


= 188 sectors 


Since key 1 has tne largest block size (354 words in 3 sectors), its blocking factor is unchanged. The blocking 
factor for key 2 is edjusted so it has the same block size. The following values sre used: 


ES=11 «——————- etry size calculazed for key 2 


BS=384 «————. b!ock size of key 1 (now used for key 2, also) 


FL=1024 «——————- default file size in words 


NB=3 «<———————- number of sectors needed for each block of 384 words 


Calculate the new blocking factor for key 2: 


*BF= (L(384-5/11J -1)/2 1x2 
=(134.4J-1)/2 1x2 
©f 16.5 1x2 = 17x2 = 34 


FS=( 1024/341x2) x3 
=(f 30.17 x2) x3 = 186 sectors 


Surmimieg th ws.o file sizes and adding two sectors for control und key descriptor information, the total file 


size in sectors is: 


516 + 186 + 2 = 70-4 sectors 


on 





*The algorithm to calculate BF can be expressed more simply if the result can be checked for an even 
number: 


BF=LBS-5/ES J If BF is an odd number, set BF=BF-1 


FIGURE 6. Calculating file size (FS) for multiple 
Keys. 
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FIGURE 6 shows how the size of the KEYFILE is 
block Can be a minimun of half full, 
assigned as would be needed 


Data used 


Faster with FAST KSAM 


a 


by VERIFY 


Current data record, 
& key comparison area 


Current dats biocx —__—___4 


1 key block per buffer 


a 
ee 


KSAM 
Extra Data Seginent 







STATISTICS 
CONTROL BLOCK 
& 

KEY DESCRIPTOR 
BLOCK 










Working Storage 






Data Block 
Buffer 





Key Block 
Buffer 







Key Block 
Buffer 







up to 20 
Key Block 
Buffers 





calculated. 
twice as many KEY ENTRY blocks are 
if each block were full. 


Since eacn 


A (approx. 1%K bytes) 


B (maximum 4K words) 


C  #of key block buffers 


x key block buffer size 
(maximum size per block 
=4K bytes) 


Total Extra Data Segment size = A+ B+C (maximum 32K bytes) 


FIGURE 7, 


KSA 


XDS. 
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Faster with FAST KSAM 


KEY BUFEERS 


The new features of FAST KSAM can now be put to use. An extra data 
segment (XDS) is used to handle all 1/0 to the KSAM file. The size of 
this XDS is limited to 16K words. Approxiametly i°-1/2k are used for 
overhead and control information. Only one buffer is used for the 
DATAFILE: it has a maximum of 4K words ana is the size of one block from 
the DATAFILE. We use a program that calculates the best BF that will 
fit in 8 or fewer sectors so the data puffer will be 1K or less. The 
rest of the XDS can be used for KEY ENTRY buffers. 


To find how many buffers could be used (all calculations in words): 
1. Subtract the 1°1/2K of overhead. 


2. Subtract the size of the data buffer. Lets assume 
1K. 


3. Divide wnat’s left py the size of a KEY ENTRY 
blocke--default is 1K. 


4. Round the answer down to the next integer. 
So, (16K = 1°1/2K °° 1K) / 1K = 13 buffers. 
To get them: 
sFILE ksamtile;DEV=,,13 


It this would cause the XDS to be larger than 16K words, KSAM will auto- 
matically decrease the number of buffers. 


Since KSAM does have a fairly good algorithm for choosing the default 
numoer of key buffers (see FIGURE 8), once the file has stablized you 
may wisn to restrict the use of the FILE equation to loading or othere- 
wise making large numbers of changes to the file. If the tile is empty, 
KSAM will default to the minimal number of buffers for the type of open 
specified. For this reason you should specify the number of buffers you 
will actually need as KSAM will not allocate more buffers as tne file is 
filled. 


Eacn process that opens the KSAM file gets its own XDS. The number of 
bufters in these XDSs are dependent upon the type of open specified and 
tne numper of keys in the file at the time of opening. Therefore, these 
XDSs could nave diftering numbers of key buffers. 
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Faster with FAST KSAM 


Access Type Buffers Assignez 


Read Only Access 1 buffer per levcl in primary key structure 


Write Only Acciss 3 buffers per primary key + 3 buffers per alternate key + 3 buffers 





Other Access 
(Read/Write or 
Update) 


(up to a rnaximum of 20 buffers) 


1 buffer per level in + 1 buffer per level + 3 buffers 
primary key structure in alternate key structure 


FIGURE #. Default key buffers allocated at FOPEN. 


DUPLICATES 


Tne other ISAM packages that 1 am familiar with do not allow for dupli- 
cate keys. At first glance, one would think it is a blessing that KSAM — 
does; but to paraphrase the LAB: If there are more than 10 duplicates 
for a particular key, then don’t have this key or make it unique. 


Wnenever a key is added to the file it is added after any duplicates 
tnat exist for that value. KSAM must search the KEYFILE to find that 
last entry. A START causes a search for the first entry. 
Two of the most common ways of making duplicates unique ares 
1. Put a time stamp (HR:MM:SS) after each key. For 
calls less than i sec. apart, this would still 
leave tnem duplicates. 
2. Put a copy of the primary Key after the other keys. 
In COBUL the primary key must be unique. In the Medical Index case it 
was 7 bytes long so we were not any worse off than using the tine stamp. 
Another method will be proposed in the ENHANCEMENT section. 


TIMINGS 
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Faster with FAST KSAM 


tem. The 
A stand-alone environment is not readily available on our sys 

following timings show obotn CPU seconds and WALL TIME to load 10,000 
records into an emoty KSAPM tile. 


Default Buffers 13 Buffers 


KSAM expected duplicate 
keys and duplicate keys 
were loaded. 


1111/5333 933/1010 





KSAM expected duplicate 
keys; but all keys loaded 870/4627 


326/484 
were unique. 


KSAM expected unique 


keys and unique keys 1183/5992 


389/567 
were loaded. 


FIGURE 9. This shows the CPU seconds/WALL seconds 
to load 10,000 records into an empty KSAM 
file. Three keys were used--7 bytes, 20 
bytes, and 43 bytes. The BASIC procedures 
were used to load the file. 


ONLINE BENEFITS 


lizing unique 
By correctly specifying the numpoer of Key buffers and uti 

keys there will be a marked improvement in througnput. But the other 
benefits even outweigh this. 


has 4 records 
An example please: two users will access a KSAM file that 
in it. we will assume 1 defined key and a KEY ENTRY blocking factor of 
4. Therefore, the ROOT KEY ENTRY block is full. Any new records added 
to the file will cause a key=blocK=split. we proceed: 

i. Both users open the file for shared access. 


2. User A LOCKS the file and reads the first two 
logical records. 
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3 User A UNLJICKS the frle and User B LOCksS it, 


4, user ® writes a record whose logical value places 
itt #3. 


oe OSer B URLUICKS the file and posts tre Lpcated 
outfecrs. 


oO. Tne tile now has 1 KFY ENTRY in tne RUOT block. 
inis points to two other blocks. fhe first pwlock 
contains the keys User A just read. Tne second 
block contains the two keys User A expects to see. 
In actual practice he should get the record that 
User B just posted. 


7. User A LOCKS tne file again and calls for the next 
READ (sequential of course), 


8. The next KEY ENTRY that User A would previously 
have used would have been #3 in the ROUT. At tLeast 
that is all that KSAM knows. But the KOOT now has 
only one entry. Since the 3rd entry no longer 
exists we are at the end of the tile, so return an 
EOF condition. 


User A was lucky. If there had been many KEY ENTRY blocks and User A 
had be@€n down several levels, tne following possibilities could have 
happened (we nave seen results to indicate they nave happened to us): 


1. The current block would no longer be included in 
the Key structure; but tne process is not aware 
that is has been placed in a free buffer list, s0 
the process uses it. 


2. The same for a previous level; te, the ROUT or one 
of the intermediate levels was moved away from 
where we expected it after the last access. 


3. The current or a higher level was reshuffled. All 
blocks are active; but not necessarily in the same 
tree structure as before. 


we turned this in as a bug--and promptly got laugned at. This is one of 
those dubious features we all enjoy. KSAM will not Keep track of any 
reorganization that may occur while tne file is unlocked. The buffers 
are refreshed by the physical blocks that were last used in the XDS. 
KSAM will_.not check to be sure that these contain the logical values 
last used. So, you must reposition the pointer yourself. You can do 
tnat by using the START procedure with a relop of Strictly greater than 
tne key tnat was returned in the last read even though a number of 
cnanges may have occurred to the point of deleting the record last read. 
Tais 18 a multieuser online environment, right! Agains 
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1. LOCK the file. 


2. Do a START using last key read and greater’. than 
relation. 


3. Now do that sequential READ. 


4. If you were going to do a READBYKEY or a REWRITE in 
random/dynamic mode, then items 2 & 3 are not 
needed. 


5. UNLOCK when done. 


Tnat process can’t be done with duplicate keys. If the last READ was in 
the middle of a duplicate key, the START would bypass the duplicates not 
read. Unique keys are a MUST in order to do the above, 


In the case of updates to the fille, one more item {js needed==“RECORD 
LOCKING. Set aside one byte in the record to be a locked/unlocked flag. 
wnen a record is read prior to updating it: 


1. Check that field--if it is locked, then report it 
as being lockea or work out a mechanisin to hang 
until it frees up. we don’t like hanging up, since 
a process might abort and leave a record flagged as 
locked. It hnasn’t happened in 6 months at our 
Site, but? If unlocked, then continue. 


2. Set the flag for lock. 
3. REWRITE tne record. 


Now you can UNLOCK the file and KNOw that when you’re ready to update 
tnat record it WILL BE the SAME. P.S. Be Sure to reset that flag! 


PROPOSEL_ ENHANCEMENTS 


If we find time between this writing and the International meeting, we 
may have a set of COBOL copylibs to simulate this. We want KSAM to do a 
lot of the dirty work for uS, so: 


1. it should automatically call the LOCK for us if we 
failed to. Of course, only we know when to UNLOCK, 
so this is only a onesided benefit. It woula still 
be useful. 


2. The first call following a LUCK (whether directly 
Or by #1) should cause a call to tne START to 
reposition the pointer, unless this is a READBYKEY 
Or START or RkwRITE in random/aynamic mode. 
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3. Force all keys to ve unique by: 
A. Assianinc a aouble-sord integer as the Primary 
key. 
b. Appending this integer (4 bytes) to the ena of 
every key. (Uf course, if one key ends at the 
Place tne primary key takes Off, then just 
increase tne length of that key.) 


4. Allow record locking (if necessary, set asice one 
byte) le, a read with lock option. 


It everything else in KSA™ workea tne same, we coulo then detine a next 
step that would reuse space left by deleted recoras, 


1. The record with a mprimary key of zero shoulda nhnolg 
two pointers: 
A. The next integer tc be used for the Primary key 
(le, EOF pointer). 
B. Tne primary key value of the most recent recora 
deleted. 


2. The alternate keys for Primary key ot zero ano a}] 
ageleted records should he set to HIGH@VALUES except 
for tne last 4 bytes which would be a COPY of the 
Primary key. 


3. An ENF pointer would be returnegq upon reaoindg a 
record with HIGK"VALUES jin al bytes except tne 
last 4 of any key. 


4. Every deletea record would nave the erimeary key 
value of the previously deleted recoro. (A push 
doan stack or free list chein.) 


>. whenever a REWKITTE occurs it woulu pe kKeyeo otf of 
the primary key. 


mo. A WRITE would first use up tne tree list cnain 
werore incrementing the primary key. 


You wlll notice the anove has been specitied in sucn «a menner thet a 
user ot tne current wSAM could write a set of Lrocenures to Mare KGaA: 
function as suggested. Now for the bomrsne)). hOAb alreany atpenas a 
dovole-word inteaer to Abs Keys. It is tore prorerly called tne oeata 
record rointer. 


If the lab woul’sd co the above, they couls: 10 1’t at a more  sinple leve) 
(ie, they wouldn’t need to use the brimary Key). 


1. They could use tne fF rFOInter aS Now, 


B-74.14 


Faster witn FAST KSAM 


2. They would neea to set up a free list chain for the 
DATAFILE (they already have one for the KEYFILE). 


3. They would have to keep track of the key and record 
number of the last logical record read. Then auto- 
matically reposition according to the first set of 
Proposed enhancements. 


4. They already append the record pointer to the keys 
sO no physical change would be necessary*=*as would 
be if one of us users was to try. 


2. In short, the lab nas all the information necessary 
to do tne job except for tne free chain list in the 
DATAFILE. 


Whether or not the lab does this enhancement, we already do something 
Similar by using the primary key to append to all others: but we intend 
to write the procedures necessary to make KSAM look like our proposal. 
Anypody interested? 


Tnere are some enhancements that only the lab can do: 


1. A central XDS similar to the recent IMAGE update. 
Only one XDS per tile no matter how many users are 
using tnat same file. A small XDS may be needed 
for each process to keep track of the last logica) 
key value and other local data. 


2. Implement a LOCKing similar to IMAGEs. 


3. UK, let’s go for it! USE THE IMAGE CALLS TO HANDLE 

KSAM. This means: 

A. A schema processor to look for data sets type k 
Or KSAM, 

Be we could have FAST sorted chains. 

C. In fact we could now have sorted Master files 
(just a KEYFILE to point to the Master set 
entries). 

De. NBFIND would also tunction as START for  KkSAM™M 
tiles. 

FE. DBGET would take over as: 

- the current calculated DBGET would work § for 
READBYKEY. 

- anew mode for seyguentia] reaus as opposed 
to serial. 

F. Tne DBLOCK would give the same type of locking 
scneme for KSAM as is now being enhanced for 
IMAGE. 
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Faster with FAST KSAM 


Tnese ideas will be implemented in our shop as far as possible. 
to write a set of routines that will handle both the KSAM 
proceaures. If the lab pneats us, 
race! 


we plan 
and IMAGE 
we shall be very happy to conceed the 
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INFORMATION MANAGEMENT: AN INVESTMENT FOR THE FUTURE 
DAVID C. DUMMER 


D.C. DUMMER & ASSOCIATES LIMITED 


We are all witnesses to the current information explosion that affects 
every aspect of our lives. Some of us may wonder if this explosion can 
be contained and controlled. 


Computer technology has nurtured the evolution of devices that perform 
data storage and manipulation functions at reasonable cost. Government, 
industry and commerce have rapidly made use of such devices in an effort 
to improve information systems for decision-making processes. The better 
the quality and timeliness of information, the more powerful and competi- 
tive the user can become. 


Unfortunately, the technologies that support the effective utilization 

of information systems have trailed the dramatic advances in computer 
hardware and software. There is still not a general awareness that data 
is an organizational resource that requires management control, admin- 
istration and involvement. The first illustration draws an analogy to 
other resource management areas in that good data management will direct- 
ly benefit information systems needed for decision-making. Data manage- 
ment is, however, a far less developed area than either financial or per- 
sonnel management. Very few organizations that have attempted to esta- 
blish a corporate data base resource have been completely successful. 

The history of integrated management information systems contains many 
failures, and indeed, the downfall of several organizations. 


Like many technological advances, those related to information handling 
are full of promise, yet also hide many dangers. Failures can generally 
be attributed to two major causes: the incomplete and incorrect applica- 
tion of the technologies and resulting information handling facilities; 
and the lack of necessary changes to organizational structure to comple- 
ment the integrated information structure. 


It is relatively easy for senior executives to decide upon a data re- 
source management strategy, but it is a far different matter to under- 
stand all of the different components necessary for strategy success. 
These problems are compounded by the fact that there are very few pro- 
fessionals in this area with adequate levels of experience. 


‘The second illustration highlights the resistance that corporate manage- 
ment typically meets in the introduction of data base technology. Re- 
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INTRODUCING DATA BASE TECHNOLOGY TO AN ORGANIZATION 


RESISTANCE TO: 


- CHANGE IN METHODS AND 
PROCEDURES 


- LOSS OF DATA OWNERSHIP 


- LOSS OF DATA CONTROL 


- CHANGE IN THE POWER 


STRUCTURE 


- CHANGE IN THE STATUS 
OF DP USERS 


- CHANGE IN STAFF 
REQUIREMENTS 


CORPORATE OPPORTUNITIES: 


IMPROVED METHODS AND 
PROCEDURES 


CORPORATE DATA 
MANAGEMENT 


CORPORATE CONTROL 
STANDARDS 


PROFESSIONAL DATA 
MANAGEMENT 


IMPROVED DATA 
UTILIZATION 


REDUCED COST AND 
ABILITY TO CONTROL 


sistance can occur in both data processing and user departments as the 
need for new responsibilities and procedures becomes evident. Few exec- 
utives are equipped with all of the correct rebuttals to the criticisms 
that result from the resistance. So intense can the resistance become 
that often the data base approach is introduced in a compromised manner 
and one that is far from beneficial to the organization. 


Corporate opportunities that can be realized by the data base approach 
are immeasurable and there is an ever increasing responsibility on the 
data processing profession to ensure that the approach is fully under- 
stood and supported. The second illustration also enumerates the re- 
spective benefits that can accrue to the organization, but, in order to 
achieve these benefits, the organization must be willing to invest the 
necessary developmental resources into the data base approach. 


Once the data base approach has been adopted as a means to achieve data 
resource management, it is important to realize that a data sharing 
concept has been introduced within the organization. That is, the con- 
mon data in the corporate data base is to be shared by all those in the 
organization that have a right and need to access the data. The major 
technical facility that supports data sharing is a data base management 
system (dbms). A dbms is often presented as the solution to the pro- 
blem of data sharing, but, in reality, it is just one of the facilities 
needed to achieve data sharing in a resource management environment. 
Crucial to the success of data sharing is data administration, some- 
times referred to as data base administration. Data administration en- 
compasses the other facilities, procedures and tools needed to manage 
the data base. The third illustration shows the major aspects of data 
administration. The degree to which an organization addresses and im- 
plements facilities in these areas depends on the complexity, integra- 
tion and value of the data together with limitations imposed by the 
budget available for data management. 


First and foremost of the required administration facilities is a data 
dictionary and directory (DD&D). The DD&D is essentially an information 
system about the data and data processing systems used in the organiza- 
tion. To the person or persons responsible for data administration, it 
represents a tool to document and control the data base facility. If 
the data base driven information systems are an integral part of the 
operations of the organization, then the data base will normally have 
to be flexible and changeable, to reflect and support business dynan- 
ics. The DD&D should be designed and organized to provide for this 
type of environment. 


For some organizations, the DD&D will evolve into the hub, or nerve- 
center, of their data processing facilities. It will control, monitor 
and service the corporate data base together with the associated in- 
formation systems. 


B-@8.04 


DATA SHARING REQUIREMENTS 
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There are other data administration facilities which complement the 
DD&D, many of which are still in the evolutionary stage. These facili- 
ties are aimed at such considerations as ensuring that the corporate 
data base is always organized in the most efficient manner, and is nor- 
mally available, and is recoverable in the event of system failures. 


Another important aspect of information systems concerns auditability 
and performance measurement. These are typically topics that are con- 
sidered only at system implementation, but a data administration func- 
tion can ensure that system audit becomes a design parameter during 
analysis and development. 


The fourth illustration shows the responsibilities of the person (Data 
Administrator) or persons performing the data administration function. 
Like other resource managers, the Data Administrator (DA) must be 
placed in an organizational structure such that he or she can coordin- 
ate and be held responsible for all of the technical and administrative 
components needed to effect data sharing. The DA is responsible to the 
corporate executives to inform them of requirements and situations 
which demand their participation and decision-making; and then to enact 
and administer the resulting policies and data control measures. The 
DA is responsible to data processing users in the response to queries 
and requests and in the provision of facilities that make data more ac- 
cessible to those with the right to access it. The DA interfaces with 
the systems group in order to obtain the hardware and software which is 
required to provide and support the data base and processing environ- 
ment for which he or she is responsible. The final interface within 
the organization is to the corporate data management system which em 
bodies all of the facilities needed to provide control and administra- 
tion of the corporate data base. 


With a perception of the data administration requirements, the specifi- 
cation of a suitable DD&D can be detailed. The fifth illustration 
lists the major components of a DD&D. Again, the complexity and con- 
tents of the DD&D should match the requirements and budget of the or- 
ganization. The components cover the documentation of how data is per- 
ceived in the organization (documents, forms, used by department, 
etc.); how data is structured in the data base designs; and how data is 
used in the data processing systems. Supporting these directories are 
dictionary and directory entries which document data items and their 
attributes, data validation rules, data security measures and data item 
synonyms and associates. 


The sixth illustration depicts the role of the DD&D in an organization. 
It is the method by which the DA documents, controls and administers 
the corporate data base and information systems. It is a source of in- 
formation and a design capture device for data base and information 
System designers. It is a source of information and a change capture 
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device for the maintenance group, as existing data bases and informa-~ 
tion systems are modified and enhanced. It is a source of information 
to users who can discover what data is available without the need to 
contact the DA or associated staff. This is particularly true in the 
case of an online DD&D which can support information queries from the 
users. 


One data administration topic that is currently receiving a lot of at- 
tention concerns data security. The seventh illustration contains a 
list of items needing protection consideration and a list of events 
that can constitute a threat to the data and system security. The 
first list identifies that security measures applied to data files and 
data bases are of little value if security measures are not applied 
to: the computer memory and storage devices during data processing; 
the hard copy data listings and reports distributed in the organiza- 
tion; the data transmission lines where remote terminals, workstations 
or satellite computers are involved; and the security measures them- 
selves. In a similar manner to security provided by lock and key, 
data base and processing security is only a deterrent and each extra 
level of security will typically involve exponential increases in the 
cost and time of the security measure implementation and practice. 
These extra measures of security protection should be applied only 
where sensitivity of the information involved warrants it. 


The second list covers the major threats to the security and availa- 
bility of data. These are important considerations in a data sharing 
environment since the data has been organized in a logically or phys- 
ically central location and it is collectively more vulnerable to 
security violation. One of the most important tasks for the DA in an 
organization is to achieve the correct balance between data accessi- 
bility and privacy. 


The challenge that faces most organizations at this time is the ef- 
fective creation of a data sharing environment. It requires an in- 
vestment in terms of people, funds and organizational change; but the 
future benefits of a well managed data resource to aid and make pos- 
sible decision-making are immeasurable. 


The presentation of the paper will enlarge upon these topics and sug- 


gest various methods of evaluating and implementing data administra- 
tion facilities and procedures. 


B-88.10 


DATA SECURITY 


WHAT TO PROTECT? 


PROTECT FROM WHAT? 


DATA ITEMS AND DATA FILES 
COMPUTER MEMORY AND DATA 
STORAGE DEVICES 


DATA LISTINGS AND 
INFORMATION REPORTS 


DATA TRANSMISSION 


SECURITY SYSTEM(S) 
AND PROCEDURE(S) 


HUMAN AND SYSTEM ERRORS 
ENVIRONMENTAL ACCIDENTS 
OR CATASTROPHES 


MISCHIEVIOUSNESS AND 
FRAUDULENCE 


INDUSTRIAL AND POLITICAL 
ESPIONAGE 


B-088.11 


SIGMA - GENERALIZED INFORMATION SYSTEM 


by Manreos A. X. de Carvalho 
Systems Anakust 
Prxomon Engenharia S.A. 
Brazr.k 


B-@9. Gl 


TABLE OF CONTENTS 


INTRODUCTION 


2.1 


- SYSTEM DESCRIPTION 


Data Structurze 

2.1.1 Structure Overview 

2.1.2 Data Base Straucturze 
2.1.3 Linkage among Data Bases 
Data Base Handling 


2.2.1 Data Base Updating 
2.2.1 Information Retrieval 


Reports 

2.3.1 Definition 
2.3.2 Selection 
2.3.3 Edition 
Additional Resources 


2.4.1] Data Editing 
2.4.2 Handling of Dates and Monetary Values 


» SYSTEM PERFORMANCE 


B-99.@82 


l. 
INTRODUCTION 


SIGMA (Generalized Information System) is a system for information handling, 
which provides the user with the following capabilities: 
. Batch and interative data entry 
. Selection of information through key-words and pre-defined coditions 
. Report generation defined by the user 
- Storage of data in more than one data base so that hyerarchical structures © 
can be processed. 


SIGMA was developed by the Systems Division of Promon Engenharia S.A. to assist 
Project Management in: 


. Project Control 

. Resources Control 

. Development of Interim-Sys tems 
. Budgeting 

. Information Control 


Ze 
SYSTEM DESCRIPTION 


SIGMA 1s a system composed of a set of programs operating on a predefined data 
base structure under IMAGE. The information stored in the data bases is defined 
according to the user's application and it can be selected and editea in a 
report form by means of an oriented language. 


In this section we will show: 


. Data Base Structure 
. Reports Available 
. Additional Resources 


2.] 
Data Base Structure 


Zohel 
Structure Overview 


In the structure handled by SIGMA, the information can be grouped in more than 
one Data Base. 


The data bases can be interconnected to form a hyerarchical structure. 
To illustrate SIGMA structure, consider the following example: 
. We are controlling a set of information about equipments specified in a project. 


This control begins with the specification of equipment by the engineering 


department up to its purchase by the purchasing department. Control is executed 
through four documents: 


. Equipment List 
. Requisition 

. Inquiry 

. Purchase Order 


To each document there is associated a set of information as follows: 


Equipment List 


. Code (Tag Number) 
. Description (Technical Characteristics) 
. Cost 


. Scheduled delivery date 
. Importation flag 


& Requisition code | + LINK INFORMATION 


Requisition 


. Code 
. Scheduled issue date 
. Issue date 
. Date received by purchasing 
.. Note 
E Purchase order code | jaa INFORMATION 
i.. Inquiry code 
Inquiry 
. Code 


. Scheduled issue date 
. Issue date 
. Supplier | 
2 
3 
.. Note 


Purchase Order 


. Code 

. Supplier 

. Issue date 
. Order value 
. Note 


To each document there corresponds an IMAGE DATA BASE, which are linked each 
other as shown in the picture below. 


DBEQ 


TAG REQUISITION RELATED 
NUMBER CODE INFORMATION 





DBREQ 


REQUISITION INQUIRY 


RELATED 
CODE CODE INFORMATION 





DBPO DBIN 


RELATE RELATED 


D 
INFORMATION INFORMATION 





- DBEQ - Equipment data base 

- DBREQ - Requisition data base 

- DBPO - Purchase order data base 
. DBIN - Inquiry data base 


This data stored have the following hyerarchy: 


. Purchase Onder 


re 


. Requisction 


. Equipment 


EI 
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Zed 
Data Base Structure 


SIGMA data bases have their own structure and they are dimensioned according 
to user's requirement. 


There is no limitation to the number of IMAGE data bases used in the 
applications of SIGMA, this being indicated by the nature and complexity of 
the information under control. 


In the definition of the SIGMA data structure, we shall use the following 
concepts: 


. ITEM (CODE) 
. DATUM(MNEMONIC) 
. INFORMATION UNIT 
. KEY WORD 
. ITEM 


Is a set of information identified by a CODE. The SIGMA data base is 
constituted by the set of all ITEMS. 


. DATUM 


Is an information identified by a mnemonic and associated to an ITEM. 
The ITEM is constituted by a set of DATA. 


- INFORMATION UNIT 


Is the triple: 

- CODE (of the ITEM) 

. MNEMONIC (of the DATUM) 
- DATUM 


. KEY WORD - 
Is the double MNEMONIC + DATUM especially chosen by the retrieval of ITEMS. 


In the next figure we have a graphic representation of these concepts. 
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In the next figure we have an example of the data base DBEQ, which contains the 
EQUIPMENT LIST. 


ITEM 010 - B - 006A 


}DES |PHOSPHATE INJ. DUMP 
010-B-006A 7500 


ESD | 08/11/78 





011-B-002A 


QUENCH OIL DUMP 
DBEQ 011-B-002A 90000 


ESD | 05/02/78 





011-P-013 


DES | ETHANE PREHEATER 


011-P-013 CST | 18000 


04/05/78 
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SIGMA uses IMAGE's data bases with a structure as is shown in figure below: 


mcoD ML TEM MNREF 











DTEXTO | DPINV 






NITEM SIGLAT. | TRECHC 
ty pay 





The detail data sets have the following characteristics: 


. Code data set (DCOD) 


In this detail data set are stored the CODES of the ITEMS. The elements of the 
data set are: | 


.. the code (COD) 
. the atualization flag (FLAG) 
. the internal number of the item generated by the system (NITEM) 


. Text data set (DTEXTO) 


In this detail data set are stored the information unities. The elements of 
the data set are: 


. the number of the item (NITEM) 
.. the mnemonic of the DATUM 
. the DATUM 


. Inverted search data set (DPINV) 


In this detail data set are stored the association: number of item (NITEM) - 
number of keyword (NREF). 


. Keyword data set (DREF) 
In this detail data set are stored the keywords. The elements of data set are: 
. Keyword (REF) 
. Number associated to keyword (NREF) 


This structure is handled by 10 programs, seven in SPL and three in FORTRAN. 
The programs are funcionally distributed as follows: 


SIGMAO] 


 STGMAQ2———_ DATA ENTRY 
TOMO” REPORT SELECTION 

| SIGMAOS —-REPORT EDITING 

; SIGMAO6 REPORT DEFINITION 
| SIGMAOT 

. SIGMAOS 

Siauo8 > puxiLtan PROGRAMS 
| SIGMAIO 


Zetes 
Data Base Linkage 


SIGMA data bases are independent among themselves regarding creation 
and updating. 


In the process of information retrieval however, it is possible to agree with 
various data bases, since there are linkage elements among the data bases. 


A linkage element between two data bases is a data element common to two data 
bases. In one of them it is necessarily a code. 


The figure below shows the linkages among data bases DBEQ, DBREQ, DBIN, DBPO. 


DBEQ 


TAG REQUISITION 


NUMBER CODE INFORMATION 





DBREO 
REQUISITION —— INQUIRY 
CODE a CODE INFORMATION 





DBPO DBIN 


PURCHASE 
ORDER INFORMATION INFORMATION 


CODE 
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2.2 
Data Base Handling 


222051 
Data Base Updating 


Data base updating is performed through four commands: 


. ADD 

. REPLACE 

. DELETE 

» EQUIVALENCE 


. ADD 


Ee 


A code, [/code,] mnemonic," data” 


A 011 - B - 011A,CST,"4000" 
A 011 - B - O11A/011 - B - 011A,ESD,"01/06/78" 


. REPLACE 


R code, [/code,] ,mnemonic," data” 


R 011 - F - 012,CST,"700000" 
R O11 - F - 012/011 - F - 013,ESD,"06/03/78" 





. DELETE 
[i code, ], inmenonic] 
D O11 - B - 002A 
D011 - B - 002A/011 - B - 002B 
D O11 - B - 002A/CST 
D 011 - B - 002A/011 - B - 002B,CST 


For batch processes, it is possible to update the data base through records, with 
pre-defined lay-outs. The next figure shows this alternative. 
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pe beh 


FI OL2OR PROGEM-LISTA DE EQUIPAMENTOS Ficha 0] 
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taL ae eS inion, “cnn 5 OPER AG ro 
g4A- : = ae ULIGH, PRESSURE STEAM SUPER HEATER. | 


e ummandl 
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: 
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a 


vLEEEB EE 


Hii 
AAaN aa aaAn As 


ObSERVAGOES . 1- Os campos corressondentes as colunas 17, 31,336 74 2- Quanto a origem do fornecsmento preencher o Campo Correspondente conforme descrito cbars0 


deverao ser preencnidos odedecenda uma das seguintes opcées | TE~ Equipamento importado 


letrqg A = inclusda de uma novo wnformacdo BE - Equipamento nocionol ; 
letra Ro = Alteracdo de wno informocdo es:stente BR- Equipamento nacional com materia prima importada 
tetra O = Eactusco de uma enformocdo casionia OQ- Concorréncia internacionas 


2.2.2 
Information Retrieval] 


We have three types of information retrieval: 


- Through the CODE 
- Through the KEY WORDS 
- From the ITEMS which were updated 


Retrieval through CODE: 
Retrieval through the CODE is executed by the command: 


L code, | Feode | [imemonic] 





=2L Oll- 5B -002A,DESs 
* Oll- B -002A 
_ DES QUENCH OIL PUME 
=>L Oll1- B -002A 
* 011- B -002A 
CST 90000 
DES QUENCH OIL PUME 
‘-ESD 02/05/78 
REG PR-011-31-001 
TIP IMP 
=2L Oll- B -OO2A/01l1- §£ -002EB, DES 
* 011- EB -002A 
DES CUENCH OIL PUMP 
* 0ll1- B -0025 
DES CUENCH OIL PUME 
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In this type of retrieval we have: 


. all information must be in the same DATA BASE 
. the retrieved information can only be edited in a standard form 


Retrieval through KEYWORDS 


The KEY WORDS can be combined through Boolean operators (OR,AND,NOT) making 
logical expressions which will be used in the selection of a sub set of ITEMS. 


Example 







LOGICAL EXPRESSION 





DATA BASE 






OR OR 
KEY WORD, { AND} KEY WORD,. {AND } KEY WORD 
NOT NOT ” 


The retrieved ITEMS can be edited by a user pre-defined report. 
Retrieval through ITEMS 


The third type of retrieval is that where only the ITEMS which were updated 
in a given period are retrieved. 


We nee see in more detail these two last types of retrieval in the next 
section. 


2.3 
Reports 


The printing of reports requires three phases or steps: 


. Definition 
. Selection 
. Edition 


7a ee 
Report Definition 


The reports are defined through an oriented language: 
The following elements are supplied in the definition of a report: 


. Report title 

. Selection specification 
. Heading specification 

. Column specification 

. Sort specification 


In the next figure we show the definition of three reports. 
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. REPORT 1 


The characteristics are: 


. All information is in the same data base 
. ALL ITEMS are selected 


In this report we have: 
. The information is in three data bases 


{ BEGIN "REP{%, 
2 FLAGHS My 
3 «€ SELECTION SPECIFICATION »> 
r) Arz="$SSsALL EQUIPMENTS", 
Ss «< HEADLINE SPECIFICATION p> 
6 CABEC#= * EQUIPMENT LIST REPORT, 
7 CARFEC8#2 * PROJECT CODE PSOE, 
8 CABEC8= " REPORT CODES REPI"y 
9 «<< COLUMN SPECIFICATION >> 
10 COLUNA$=COD," EQUIPMENT CODE", 14, 
14 COLUNASSDES3, "EQUIPMENT DESCRIPTION", 353 
12 COLUNAS=ESD,"SCHEQULEDDELIVERY", 93 
13 COLUNASETIP,"{MP%,3y 
14 COLUNASSC8T," COST"™,10,(M)3 
15 << SORT SPECIFICATION >> 
16 SCONTROLES=COD,(1,43,A} 
17 ACONTROLEISCON, (7,3) ,A9 
18 SCONTROLE22COD,(S,2),A8 
19 SCONTROLE SSCOD, C41,8),A3 
20 END, 
- REPORT 2 


- Only the imported equipments (A:=TIP:IMP) are selected. 


{ BEGIN "REPQN, 

2 FLAGS” My 

3 €¢ SELECTION SPECIFICATION »»> 

a AUBFTIPZSIMP Hs 

Ss €¢ HFAOLINE SPECIFICATION >> 
6 CARECos "© REQUISITION 
7 CABECtR ® PROJECT CODES PSO18) 
8 CAREC#@ * REPORT CODE? REPAM, 
9 

| 

{ 

{ 


«< COLUMN SPECIFICATION »>> 


REPORT © ON 


LY YHE EQUIPMENTS TO BE IMPORTED", 


) COLUNASSREGQ," REQUISITION CODE", 333 
| COLUNA98COD,"® EQUIPMENT CODE",{Qy 
2 COLUNAGROES, "EQUIPMENT DESCRIPTION*®,323 
13 COLUNAGARST,*SCHEDULED ISSUE", 9, 

a COLUNAGBRID," ISSUE DATE"®,8) 

18 COLUNAt@RRP, PRECIVED PURCH,", 83 

16 << SORT SPECIFICATION > 

17 SCONTROLESBREO, (2,43), 1, Ay 

18 SCONTROLE&SCOD, (1,4) ,A% 

19 SCONTROLESBCOD,(T,3), Ay 

20 SCONTROLE?#8COD0, (8,2),A3 

21 SCONTROLE#8COD,(1354),A7 

22 END, 


. REPORT 3 
In this report we have: 


. The information in the three data bases 


. Only the items that were updated in the last period (FLAG:="*") are 
selected. i 


NOTE: This period is defined by the user of the SYSTEM. 


{ BEGIN °REPJ%, 

2 FLAG ar ats 

3 €< SELECTION SPECIFICATION >> 

Pr) Ape®SSIpALlL ECUIPVENTS®y 

5 qe wWFLOLINE SPECIFICATION >> 

4 CARECa® © PUACHMASE ORDER REPORT o@ & 

7 T 26 “ONLY THE ITEMS THAT mAS UPOATED AFTER 10/05/76") 
8 CaBECis ° PROJECT COOEsS PED", 

q CaAFCye © REPORT CODES REPS%, 

10 << COLUMNS SPECIFICATION d> 

13 COLUNAE SPOT, °PURCHMASF ORDER CCOE*, 8} 
12 COLUNATEREQ,*® RECUISTTION COOE*, 13) 
13 COLUNSEBCCD,"® EQUIPMENT CODE*, 103 
qa COLUNATBSOES, SEGUIPMENT DESCRIPTION®, 323 
15 COLUNALAT IP, 240%, 3, 

16 COLUNAGBCET,*COST (3)%,9, (HR) 3 

t7 COLUNATESUP, SUPPLIER", 143 

168 «< $oa2T SPECIFICATION do 

19 SCONTACLES@PCD,(1,6),%, Te As 

20 SCONTACLE MRED, CL, Te Te As 

21 SCONTSCLES COD, (1,4), ay 

22 SCCONTROLES8C90,(7,3),a3 

23 SCONTOCLE3ECOS9, (5,2), a5 

23 SCONTROLEGBCO0, (11,4), a3 

25 TOTALIECST 

2b ENO, 
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232 
Selection 


SIGMA allows the following types of selections in the report edition: 


Through KEY WORDS (Logical expression) 
. Through CONDITIONS 
. Only the ITEMS that we updated in one period (FLAG:="*"). 


2.323 
Edition 


Edition is done in the final phase of the report issuing so that it is 
possible to use the same selection to issue various types of reports. 


SIGMA possesses the following capabilities for edition: 


. Classification of columns 

- inhibition of columns 

. totalization of columns 

. generation of columns as linear combination of previous columns. 


In the next figures we show three typical reports. 


PAG | 
21/SET/19786 16109 mORAS 
Es revS*%? LIST SEPHRT 
PE IFLT COSER PSO 
REPHPT CANES REPL 


SPF OOS OGIO OOS FOS SE OSS SSS ODEO TAP TTS TSCSESELESC TES HH SSSHHUTSTOCHTEVESSEUFECHE 


EGulouent EQUIOCUENT DESCRIPTION ACHEDULZO yup cost 
cooe OELIVERY 
Oe mec w cece ew eccw cer c cree crew ucee eee recucecceveccccccccvercceceucececseececs 
90202 B «0084 PHOSPHATE INJECTION PUMP 11/08/78 [MP 7,300 
0100 8 ©0068 PHOSPHATE INJECTION PUMP 12/01/78 IMP 7,500 
Otte 8 ©0024 QUENCH OIL PUMP 02/05/78 IMP 90,000 
Oiie 8 ©6028 QUENCH OIL PUMP 02/05/78 MP 90,000 
Olfe B ©0020 QUENCH OIL PUMP 02/05/78 IMP 90,000 
Olle 8 ©0020 QUENCH OIL PUMP 02/05/78 IMP 90,000 
Olle 8 20068 MIOOLE OIL OR‘WeOFF PUMP O3/10/78 IMP 2,000 
Ofte 8 ©0054 FUEL OIL PUMP 02/08/78 mp 2,000 
Ofle 8 0114 NSPHT A FEED PUMP 01/06/78 IMP a,000 
Olle 8 0138 NAPHTA PEED PUMP O1/06/78 IMP @,000 
Olle F 2012 WIG™ PRESSURE STEAM BUPER HEATER 06/03/79 800,000 
Olle PF e013 HIGH PRESSURE STEAM BUPER WEATER sevosz7e 800,000 
Olle P c013 ETHANE PRENEAETER 05/04/78 18,000 
Olle P 201$4 QUENCH OIL COOLER 03709778 IMP $2,000 
Olle PM ©0158 CUENCH OIL COOLER 03709776 yuP 53,000 
Olle P e015C QUENCH OIL COOLER 03/09/76 IMP $3,000 
Olie P ©0150 QUENCH OIL COOLER 03/09/78 IMP $4,000 
C1l=s P eO1SC QUENCH OIL COOLER O3/0%/78 IMP $0,000 
OS1e BP e01SF QUENCH OIL COOLER O3/09/78 MP $3,000 
Oit= RP ewes FUEL OIL CooLer O7/07/78 [uP 35,0006 
Olle FP e0168 FUEL OIL CooLER OT/07/78 KP 33,060 
Otte BP ediet FUEL OIL, CodOren O7/7077/78 up 3$,000 
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CONTINE..- 


PaG i 
217SE7/1976 16356 HORAS 
GET .ISP TTT. V@lOQsy we CHLY THE EQUIPMENTS YO BE IMPORTED 
PE- Si ecy C77Fe P3901 
BrO*aT-. COORG PEP! 


FOO Se OOOO 8888S OO SO SOTO ESOS STO S SSS SOSH SESCHTSESTOSTHSSESSESSHETETCESED 


PEQUJBITION EQUIPMENT EQUIPMENT DESCRIPTION SCHEDULED ISRUE RECEIVEO 
CODE COOE ISSUE DATE  PURCH, 

CSRS 08 OR OOH OOOO SOOT EH OOT CV EE EP TOE OE FP SOCE SCTE SSS OCE REE UES OO UDOT TEES YEE EEOC EEE UHUDELENeCEES 
PRe0109319001 010% B 006A PHOSPHATE INJECTION PUMP 01/03/77 OL/02/77 O1704797 
010" 6B ©0068 PHOSPHATE INJECTION PUMP OL/OB/77 OL/02/77 OL700777 

PReOtie3ie001 Oll* B ©0024 QUENCH OTL PUMP 01/02/77 O1705/77 01/05/77 
Olle 8B ©0028 QUENCH OTL PUMP OL/02/77 OL708/77 01/08/77 

Olle 8 ©002¢ QUENCH OIL PUMP O1/02/77 01705/77 01/08/77 

Olt» B ©002D QUENCH OIL PUMP OLs/02/77 O870S/77 OL70S/7F 

Olle 8B ~0088 MIDDLE OIL ORAWOORF PUMP OL/OZ/T7 OL/0S/77 OL705777 

Olle @ ©0054 PUEL OTL PUMP OL/ORSIY OL/0S/77 01708777 

Olle B eOL1A NAPHTA PEED PUMP OL/02/77 OL/0S/77 01705777 

Olle 8B ©0448 NAPHTA FEED PUMP OL/02/77 OL/0S/77 OL705/77 

PReOIfeuz~-00) Ollie F e012 HIGH PRESSURE STEAM SUPER HEATER OL/10/77 OL/LE/7Y O11 2797 
Olle F 043 HIGH PRESSURE STEAM SUPER HEATER O1/10/77 O4/L1/77 Of71a777 

PReOileGb~-001 Olle PM e013 BTHANE PREWEAETER OL/12/77 OL 700777 OL7L0777 
Olle P 06a FUEL OTL COOLER O6/OT/7Y Ob/10/77 06/12/77 

Otte P ©0168 FUEL OIL COOLER OL/OT/IY Ob/LO/77 OBs12/77 

Olle P wO016C FUEL OFL COOLER ObsOT/TT OB/10/77 Ob/12/77 

O11 P e046 FUEL OTL COOLER Ob/OT/77 OB/IO/77 OOsiasTT 

PPe0116G3~<002 Olle P «@045A QUENCH OIL COOLER Ob/OT/TT Ob/10/77 OAsL2/77 
Olle P s01SA QUENCH OFL COOLER COs/OT/IY ObsI0777 Obs12/97 

OL1@ P «©015C QUENCH OIL COOLER ObsOT/I7 OO/IO/T7 OOsIa/77 

Olle ® e03SD QUENCH OTL COOLER OG/OT/77 Ob/IO/7Y ObsI2/97 

Olle P ©O$SE QUENCH OIL COOLER OO/O7/77 OBsO/7F Oorsavr? 

Otte P 01SF QUENCH OIL COOLER OO/OT/77 Ob/10/77 Obsiar7? 


OOS SOO DS OS SOE OSS OSS SSO SSS SESS FOF SSSSTSSES SSS SHS SHEE FSO OT EES SSSSSESTVTSSTESFETSESESETESVSFSVTESSOCVUES 
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P4aG i 
Z2UZEFETSLIID 17a 2 wORaS 
PLaeas sh G208R BEPHRT © HMLVY THE ITEMS THAT WAS UPDATED AFTER 10/05/76 
Pa"Ject C™7Et PSO] 
GEPLCRT CODE REPS 


OTM OOOO OO OT OOOO OO OH FOO OP OOS YO EO UO YC EOE CES PEDO COROT EEE SESE SHEECTCUCE 


PIOCHSSE REQUISTTION EQUIPMENT EQUIPMENT OZESCRIPTION IMP COST (8) SUPPLIER 
ORDER Code COoE 
C94o€ . 
POS BOS OOS OOOO SOOO OST G POPES OT OES EEO O DATO CES EOE CUVEE UEC E PSUS CEST AE EUNECESEAONG 
31-2003 PROO100SI©001 C100 8B #0064 PHOSPHATE INJECTION PUMP IMP 7,300 WCRTHINGTON 
O10e A ©0068 PHOSPHATE INJECTION PUMP IMP 7,500 RORTHSNGTON 
SCSKTSTC STC TSRSSSSSSTTAAC TE STL STE ASS SSTESSCAKSKSKPSROKSSERTSELSTH CE SESRERHSETENSRESLEVCUBERGAERZERENESA 
. 15,000 
SRCRATTRRETTSASATAAASH SASS TTATSASTATSLTSSSROISTSARSESSESSSSSSEESERUSESEESESSERESERCUSETEMEREEESEER 
PReO{1e3{0003 Clie 68 e0024 QUENCH OFL PUMP TMP 90,000 WORTHINGTON 
A 
Olie B #0028 QUENCH OL PUMP TMP 90,000 WORTHINGTON 
Cite 8B ©e002C QUENCH OIL PUMP MP 90,000 WORTHINGTON 
Ollie B ©0020 QUENCH OF PUMP IMP 90,000 aOR THINGTON 
Ollie 8 «0008 MIDOLE OLL ORAWeOPFF PUMP TMP 2,000 WORTHINGTON 
Olfe 8B e005A FUEL OIL PUMP IMP 2,000 WORTHINGTON 
Olle 8B wO134 NAPHTA FEPD PUMP IMP @,000 WORTHINGTON 
Olie 8B ef0f{18 NAPHTA FEED PUMP IMP &,.000 MORTHKINGTON 
RSSTCSCSTSSTLTATS TITS TLSATEK SHC TCSSSSCHOTSESTTROTSSRARISTTETISSSRECSSESTELSSRELEETRAURATRSLTSAECKELSSEES 
372,000 


SOSSKTREMEKTTISSTCT ASSLT SHSTHLILESSKRETTTSSTASTHTRSESVSESTEUCSTTERURESESLSSRTESCTARSSREETSETSTERSESEEES 
SSPESSSTTSATITSCTSLTSATSTE TS TSSKETLSSSSTLCASSCTKHTRETSSTLSTRALALSRETSSERSSPERSSHESTSERESRESSTCESSASES 
e 367,000 


H2e001 PReQI1eG@22001 Olie F e012 WIGH PRESSURE STEAM SUPER HEATER 800,000 CONFAB 
Ollie F e013 HIGH PRESSURE STEAM SUPER HEATER 800,000 CONFAB 
SSHSTASHS TSK SSCCSTSTSSL AR SSTAVERTSRASLACKTTLSRLSSTSSTASTSSIATSRSSTIRSLHRRSTAERESISITURACRSESEARSESESES 
1,400,060 


SSSCSCSSTLTTSCLL STS SSSTSSTAKATAK TL LASHTSKHSSCSTHSTSTTLTESISSTSSTSSSUBE TRAE LARSERSLETSCEEESSESSE! TERTEESSS 
SUSTACSESSSSTTSEKLTLSTTSLLSTSSSTSTERE CSE SSESSSSSVSCTCETSACSSSSTCSSALTAKUVTSSLSCVSSRESESETREERETSVERBSSSESER 
e 1,600,000 

SCAT TCHSCSSOKTHSC TH TSSSTH SSS SSAA TSRSTSSTSSSSSLTS SACK TSRSSASARSTESSTSEERSCRSSSSSRSRASEAESRRREEHSEKERESSE 
OOOO OOOO OOO OS OOS OO OOO OO OOS COO OOOO SSO SOS O SS OED SSO E OSES OEE OTS SEO EE SESSEOOESESCESESDETESEESSEOEES 


CONTINUAe 
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2.4 | 
Additional Resources 


2.4.1] 
Data editing 


SIGMA does the following editing checks: 
. CODE of ITEM 

- Date 

- Monetary Values 


2.4.2 
Handling of Dates and Monetary Values 


- Dates 
Ee (Date, - Date.) = running days 


mae (Date, + Running Days) = Date, 


- Monetary 
. COST = COSTy{*}K, COST, {7}... (73Kn.cOSTn 
{Ky Ko --- Ky}eR 
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3. 
SYSTEM PERFORMANCE 


SIGMA performance has been kept high, considering its generality. In the 
Figure below we show some results of SIGMA application. 


. DATA STORAGE 


DATA BASE # ITEMS  # DATA PER # KEY WORDS DISC SPACE 
ITEM PER ITEM — (# SECTORS) 
ae ae a ee a ee a ee ee 
2700 23 4 5012 
2 $000 19 4 11142 
3 3500 4 0 2426 


. DATA BASE UPDATING 


. 1000 information (no key-word) = $ 25.00 
. 1000 key-words = $ 37.00 


- REPORT WITH 1000 LINES 


.. All information are in the same data base = $ 15.00 
. The information are in two data bases = $ 60.00 


NOTE: Reference values used in costs calculations: 


. Elapsed time = $ 12.00 per hour 
. CPU time = $ 160.00 per hour 
- 1000 Disc Access = $ 1.50 

. 1000 Printed Lines = $ 2.75 


. 1000 Card Read = $ 2.00 


. LIMITATIONS 


.. Maximum Number of UNIT INFORMATION per IMAGE data base = 64000 
.. Maximum Number of DATA per ITEM = 100 

.. Maximum Number of KEYWORDS per ITEM = 24 
.. Maximum Number of Characters per CODE = 14 
-- Maximum Number of Characters per DATUM = 56 
.. Maximum Number of Characters per KEYWORD = 25. 

.- Maximun Number of IMAGE data base in a report = 9 
-- Maximum Number of Columns on a report = 14 

- Maximum Number of headlines = 3 


000 


A DATA DICTIONARY/DIPECTICRY DRIVEN CLINICAL DATA MANAGEMENT SYSTEM 


ERIC S. HERBEL 
RUeChST-RULSSEL PHAR“ACEUTICALS, INC. 


AKASTEACT 

A clinical researcn cate managenent system was developed which is 
Qriven by a nierarchical cata case form of a data Gictionary using 
Varianle lengotn record KSfMmM files. Tne actual structure of the dats 
Gictionary (tne nierarchical data pase approach, and variable lenatn 
lists implemented in KSAM variable length record files) is 
e.prasized. Tne system incluaes data entry, editing, on-line 
Corrections, a variety of 164/370 resident intertaces, and 3 
generalized [AGE cata base scnena write/loader. All ot the systen 
Toagules are driven py the data dictionary. Detalls of the IMAGE 
interface are aiso é€menasized, 


UUTLIGE 


- Ine Data Lictionary/Lirectory concept in general 
e and the HP implenentation in detail 


» Overview of tne Clinical data management system 
- Vata Entry = Key to disk emulation 
- Data Preparation - editing, corrections, listing, etc. 
- Data Dictionary ~- definition, modification, reporting 
- Hata Management - Image schema writer/loader, interfaces 
to IBm/370 DbMSs. 


« IMAGE/3000 scnema writer/loadcer in oepth,. 


DESCRIPTION OF DATA DICTICNARY/DIRECTORY 


Commercially avéilaole Data Dictionary/Directory systems 
are typicelly characterized pv: 
- identification of €achn element or field (name, aliases, 
description) 
- type soecifications for each element (numeric/character, etc.), 
field size and otner onysical descriptions 
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- reporting specificetions for tne tield (Sutout toruat, 
and nefault lave) 

- Sata editing criteria - a range or table ot accéotaole values 

- a@aninistrative information sucn as wno can access various 
elements, ang information on wnich applications use specific 
elenrents 

e and maintenance responsibility for the eletent. 


A data directory is an extension of the data Gictionary concept 
intenaed primarily for machine Processing of tne neta céta(data 
which defines data). Cn tne other hand, a data dictionary is 
intended to aid in numan understanding of tne data. Apolications of 
tne directory concent reve included automatic Generation of data 
cefinitions (schema) for inout to various DBMS, 


I4PLEWENTATION OF A DATA CICTIONARY/DIRECTORY ON THE HP 3000 

Most data dictionary systems currently in use appear primarily 
concerned with aiding tre DAIA BASE ADMINISTRATOR and other HUMAN 
Gata dictionary users. we vere certainly concerned witn this aspect 
of the use of the data dictionary, out Olaced more emohasis on the 
DIRECTORY side of the concept. The net result of this etpnasis snift 
is that the majority cof application programs in the svstem are 
DRIVEN oy the central Daté Dictionary/ Directory. 


Ine Data Pictionary/Directory implemented on the HP contains most of 
tne traditional elements mentioned above, but it aoes not Presently 
contéin security information or pointers to application rcrograns, 
However some significant eéedditions were made, 


First at the element or field level a numoer of modifications 
vere made, 


e KEY fields are noted; this will cause an IMAGE automatic 
Master to be created for it 
e On-line as well as background edit specificatiOns were addjeq 


facilitating editing during data entry or later in background 


« A link to a decode table for the field was included,e.a. the 


gecode file taole entry name(used as a orefix for its KSAM Key) 


- Should the field be verified during data entry? 
- Snould the field be automatically duplicated from a previous 
record in the data entry form(set of defined records)? 


The secona and most important set of additions center of the 
masterfile’s structure, This structuring information includes 


pnysical RECORD Gefinitions, logical UNIT Gefinition, and when these 


UNITS occur, or the ENCUULTER aefinition. 


RECORD content, i.e. which elements nake up each 80 byte mesterfile 
record ( this is tne data entry medium); also where each fielg 
Starts on the record, and wnether it’s repeated as a contiguous 
Dlock or array. 
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Logical UNIT structure, i.e. which 80 byte records make up a logical 
UNIT of information (later used as the entity equivalent to an IMAGE 
data set). These logical units are generally entered together 
during data entry ( called a FORM at data entry ). Various Key 
flelds appearing on every record aid in the logical connection of 
records in a UNIT. 


These structuring entities are sufficient in most cases to process 
the data, i.e. define the data entry form, define specifications for 
the batch editor, and define the schema for an IMAGE data base, 
However, we’ve gone one step further in the structure progression - 
adding the element of time, i.e. when a group of logical UNITs are 
to occur. This is called an ENCOUNTER definition, corresponding to 
a clinical visit encounter between a subject and physician. During 
each visit, various UNITs of logically related data are to be 
collected, so an encounter consists of a list of logical UNITs. To 
facilitate automatic assignment of UNITs to a given encounter, an 
ENCOUNTER CLASSIFICATION EQUATION is included - which defines 
membership criteria, e.g. VISIT NUMBER=5 or Days’ into study is 
between 4 and 7. This structure actually captures the final 
dimension necessary to fully define a clinical study to application 
programs which will categorize, inventory and even analyze the body 
of data. 


ACTUAL DATA DICTIONARY/DIRECTORY FILE STRUCTURE 


To facilitate most efficient use of the entire system = a true 
network structure was chosen. AS a result, individuals defining a 
new data dictionary/directory can "point" to any entity already 
defined, at eitner the UNIT, RECORD or FIELD level. This automatic 
GLOBAL capability has greatly enhanced the use of the system. This 
has also encouraged use of STANDARD UNITS or RECORDS across studies. 


The data dictionary/directory system is implemented in a set of 
Variable length record binary KSAM files(except the field level file 
which is fixed length). Each KSAM file in the set corresponds to a 
level in the structural hierarchy. 


Tne linkage between the various files in the hierarchy is maintained 
by avariable length array of pointers with associated information 
pointing to the next lower level file. The pointers are in the forn 
Of KSAM Keys into the appropriate subordinate file. Selected 
information belonging to a subordinate file is often stored along 
with the pointer to the _ record(i.e., the Field start column is 
stored at the RECORD file level). This convention was adopted to 
facilitate use of global information, i.e. information used by many 
studies or records, and information thought to change most 
frequently was stored at a higher level in the nierarchy. AS an 
example, the length, edit specs, label, etc. would probably not 
Change for the field blood pressure between studies. The starting 
position on the 80 byte record probably would change from study to 
study, so the starting column was stored at the RECORD level in the 
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Figure 1. IlluStration of the data dictionary hierarchy. 


nierarchy, so many RECORDS can "point" to the same common blood 
pressure definition. 


The STUDY level file records contain descriptive fixed length 
information about a clinical study(masterfile), as well as three 
variable length pointer stacks, These three stacks contain 
Character type keys to the attached UNITs, the ENCOUNTERS and the 
data entry FORMs. The three stacks’ share contiguous space in the 
record = with the base of the FORM pointer stack just after the UNIT 
Stack and so on, The Data Dictionary/Directory is generally 
accessed from FORTRAN, so, the fixed length elements of the record 
Can be accessed after a record is read(using FREADBYKEY) Simply by 
an EQUIVALENCE of the items to the LOGICAL type buffer. The stacks 
are accessed by actually moving a LOGICAL word at a time into a 
LOGICAL typed TRANSFER buffer which has. been egquivalenced to a 
Character variable, 
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The ENCOUNTER file records contain a fixed length portion which 
includes the primary key, the ENCOUNTER CLASSIFICATION EQUATION and 
the top of stack counter, followed by a variable portion containing 
Che member UNIT stack. Each entry in the member UNIT stack contains 
a PL/I like structure (heterogeneous typed structure) containing the 
UNIT Key (character type) and the number of that type UNIT required 
in the ENCOUNTER(integer type). Each entry in the stack is accessed 
by moving a word at atime from the appropriate address in the 
record buffer to a logical type transfer puffer. The character 
variable followed by an integer variable are equivalenced to the 
transfer buffer. Note that the encounter classification equation is 
later parsed then interpreted py various application programs, 


The UNIT file records are very similar to the previous level 
records, i.e. a fixed length portion for UNIT description followed 
by a variable portion for the attached RECORD stack (also containing 
the number of each RECORD type required in UNIT). A new value is 
added to the fixed length portion of the record = the global counter 
- to aid in controlling use of the global facility. MThis is present 
also at the RECORD and FIELD level. The counter is set to 1 if the 
UNIT record is local, i.e. not pointed to by any other study, out 
it’s incremented every time it’s pointed to. This allows detection 
Of its global status(to provide for a warning on the effects of 
modifying it), as well as providing for local deletes. If an entity 
is global, and it’s to be "deleted", the global counter is 
decremented, and the pointer to it is removed(the actual record is 
not removed). If the counter is 1 and it’s being deleted = tnen 
actually FREMOVE it. 


The data entry FORM file is almost identical, 


The RECORD file record is basically the same, except that each entry 
in its member FIELD stack contains a larger neterogeneous typed 
structure, The structure includes the FIELD’s key(character), its 
starting column (integer), the member of contiguous repeats of the 
field on the record(integer) and whether it’s required (for editing 
purposes). 


The FIELD file record is the simplest = fixed length binary = 
containing all the basic information such as type, length, 
description(label), etc, 


REASONS FOR USING KSAM/3000 


Tne Data Dictionary/Directory could have been implemented using a 
set of direct access files, with an index into the top most level 
(study level) providing a table of contents. Pointers to 
Subordinate entities, e.g. pointers to all attached RECORDS in any 
UNIT, could have been the actual record address in the subordinate 
file. This approach would have been very efficient in tree 
traversal time(data dictionary hierarchy traversal). Problems 
associated with thisS approach are: 


« MPE presently doesn’t support direct access variable length 
records (variable length records being very important for 
efficient implementation of the overall structure) 

« broken pointers, i.e. bad record addresses are very difficult 
to £1x = probably requiring a dual pointer structure (pointer 
to son from father and vice versa) 

« 4 garbage collection mechanism was needed = would have been 
necessary to explicitly set this up 

- the global uSe of UNITs, RECORDS or FIELDS would have become 
extremely difficult to implement = one would need a separate 
list of availabe entities with their record addresses, 


IMAGE/3000 itself could have peen used to implement the data 
dictionary (something occassionally done in commercial systems). The 
Straight hierarchical structure of any single LOCAL data dictionary 
would have been implemented satisfactorily as illustrated in Figure 
3 


The global entity concept would have been very difficult(impossible) 
to implement using this structure, though. Also, information such 
as Field start column couldn’t have easily or efficiently been 
Stored at the RECORD level (no variable length records in IMAGE, or 
compound items as chain heads), 


The Data Dictionary/Directory was implemented in KSAM/3000 because: 


« Variable length keyed=«access records are supported, so 
variable length pointer lists with associated information 
is possible. 

- using keys aS pointers rather than actual record addresses 
greatly simplifies implementation of global entities and 
security/accuracy of pointers, 

« KSAM takes care of garbage collection automatically. 


Traversing the tree structure using keys into subordinate files is 
not as fast as direct access using a record address = but it’s close 
(KSAM takes care of that). More importantly though, this small 
disadvantage in speed is considerably offset by all other 
Capabilities gained (as stated above). 


OVERVIEW OF THE SYSTEM DRIVEN BY THE DATA DICTIONARY/DIRECTORY 


The clinical data management system implemented on the HP3000 
includes: 


e a Keyetoedisk emulating DATA ENTRY system 

e @ Set of DATA PREPARATION modules, including a batch editor, 
One-line error corrections, a masterfile inventory procedure 
and various listing/reporting utilities 

e the DATA DICTIONARY/DIRECTORY subsystem itself = containing 
an interactive..formatted screen definition/modification 
procedure, along with many reporting and auxiliary use 


-_- ——_—_ - - /- 


Utilities 

e and the DATA MAWAGENENT subsystem whicn contains seqrents for 
masterflle trackineo(orimary residencel(Ib“ vs HP), statistics, 
etc.), mastertlle tiovement, and an ITMAGE schema writer/loaser 
(Interfaces to Tb resident DBMSs also exist). 


All elements of the system are generalized and function for anv 
Study pased on intormation gained primarily trom tne vata 
bictionary/ Uirectory(sone modules are implemented using otner 
Similarly constructed central files, such as tne masterfile tracxin, 
file). 


DATA ENTKY SUBSYSTEM 


Inis is a Key to disk emulating "keypuncn" operation which Supports 
an input/verify data entry cycle, Data ls Keyed on 43 
microprocessor controllea data entry terminal(tne standara HE2543)) 
utilizing a microprogran downloaaed trom tne wuP3000. Tne cate is 
Keyed in 80 column card images using card iwtasks or FURMS wnicn are 
constructed from information contained in tne Data 
Dictionary/Directory. The microprogram allows for autonatic taobiny 
from field to field , automatic as well as manual duvlication of 
tields (from the previous record in the FOPM) ana  esutonatic 
insertion of RECORD identification intormation. tne microprogran 
comiunicates with the HP3000 in a background mode with outtering an: 
accepts keying in foreground mode. This results in instantaneous 
response at the keyboard independent of loaa on tne KP3000 &- ana 
also reduces the processing drain data entry would normally place on 
the HP, During on-line verification , the record pveing Keyec is 
matched against the corresponding recora previously keyea during 
input. Any discrepancies are resolved then. 


Completed data entry opatches are automatically routea to. the 
aopronriate mMasterfile based on information containea in the 
Masterfile Tracking file (this includes automatic suomission otf [n¥ 
bound jJobns:for tnose Masterfiles resident on the lm), 


DATA PREPARATION SUSSYSTEP 


The Data Preparation subsystem suoports oackgrounac editing ans 
inventory of masterfiles, interactive error corrections ana various 
listing utilities. All modules Of the subsvstem gain information 
from the Data Dictlonary/Directory and the «asterfile Tracxing 
Control file. 


The batch EVITUR wOrkS on -a complete masterfile or a selectes 
supset, sorts tne file by record id and other Key tielas, tnen 
produces a formatted report. Tne report is constructed usine tials 
names as column neaders and edit specifications (acceotabnle aats3 
ranqe) for flaaqging of data errors = botn from the data dictionary. 
Tne EDITOR Knows wnere to pick up each fiela on a record pasea on 
the field start column and length information, also in the fata 
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Dictionary. A similar version of the £DITOR exists on the 16%/37u , 
written in PL/I, also running off of the Data Dictionary. ‘The Ip 
resident version is run Fy jops automatically submittea from tne HP 
if the masterfile tracking file says the file’s primary residence is 
Ene JHMM, 


ine interactive EKRUR CORRECTION procedure is a fornatteég screen 
Orlented program which directly updates an Hb resident masterfile,. 
Masterfiles are maintained as KSAM tiles on tne HP, so a particular 
record to ne corrected can be located very rapidly using FREALBYKEY 
Or FFINDBYKEY., Once desired modifications are made to the record, 
it’s FUPDATEd on tne KSAP file. A log ot corrections is maintaine3 
for packing them out, or reaoplying them in’ the case of systen 
fails. 


me odatecn INVEKTGRY Drocedure takes a masterfile, sorts the file oy 
oatlient numoer, then verforms an inventory ot aata records comparing 
the data oresent to the expected data structure. dnis expected dats 
Structure = wnich records comprise a unit, and when/how many units 
are to occur = is constructed based on the Vata Dictionary EFwCOUNTER 
ang UIP structuring records. The INVENTORY proceaure runs in 
either a total inventory listing node or in an exception moge - 
listing only patients with missing records. 


tNis suosystem also includes maintenance ana reporting facilities 
for a Decove file - a KSAM/3000 based data aecodina table. An 1SA™ 
version of this decode file is maintained on the 184%/370 through tne 
HP resident maintenance system = any uodates made to the HP file 
Cause a 70M to pe automatically suomitted to the IM for identical 
Uodates to we made tnere, 


BATA DICTIOSARY/OTRECTORY SUBSYSTEM 


Ine pata Dvictionary/pirectory supsystem includes. an interactive 
formatted screen Oriented oOD/vbir definition anda modification 
Procrat, automatic codirg manual generation, a data entry FUR 
definition intertace, various reporting utilities anda translate/ 
export moaule to translate the Wata Dictionary into its 18/370 
version and export a copy of it automatically. 


Ine deftinition/moditication program uses a formatted screen (not in 
Dlock mode = but under program control) which is set ue with an 
inaented nlerarchy corresponding to that of the data dictionary. The 
formatted screen iS traversed in a manner corresnonaing to the tree 
Structure of the data dictionary. when changes are to be nage, tne 
user Simply defines the: path down tne tree to the item to pe 
cnanged, then enters the information to be modified. 


Reporting utilities exist which produce a comprehensive list of any 
Data Dictionary’s content, study encounter Structure, as well as a 
coding manual to aid data coding (prior to data entry). 
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The translate/export module traverses any data dictionary, produces 
a sequential version of it and ships this to the 1BM/370 where it’s 


used by many IBM resiacent DBMS interfaces (as well as the batch 
editor). 


DATA MANAGEMENT SUBSYSTEM 


The Data Management subsystem includes the Masterfile Tracking 
control file maintenance/report utilities, masterfile movement 
utilities and an IMAGE schema writer/loader., The entire system is 
controlled by atop level program in the Data Managenent system = 
Called the Utility controller - which runs as a very high level 
language interpreter, 


The Utility controller program of the subsystem accepts English like 
commands, parses them, and takes action on them by calling one of 
many programs in the system (using the MAIL intrinsics to pass 
information to the called programs). 


The Masterfile Tracking control file contains information on the 
primary residence of all masterfiles, predicted numver of records in 
the masterfile, and a variety of other accounting/security types of 
information. In addition, information on the existence of an IMAGE 
data base, or any other IBM resident DBMS, and the date that it was 
last loaded, is contained in this file. This information is very 
useful, not only to tell how current a data base is, but also, 
whether it already exists, and should be purged before peing 
Ccreated(recreated). 


Masterfile movement utilities are also available as a part of the 
Utility controller. The command MOVE HPD<masterfile> TO OS<dsname> 
is sufficient to prompt the system to automatically submit a job to 
move the masterfile namea to an IBM/370 resident data set(building 
it if necessary). The reverse command is possible, and in fact, 
movement between any of 4 logical origins/destinations is possible, 
The jobs to move the masterfiles in any direction are submitted 
automatically to MRJE/3000. 


The system includes interfaces to many IBM/370 resident DBMS 
packages, and to the IMAGE/3000 system. The IBM resident DSMS 
interfaces all use the Data Dictionary to create the equivalent of 
an IMAGE schema, then later in the same job, actually load the 
masterfile desired into the DBMS. The IMAGE/3000 interface submits 
a background job tO run 2 programs (with standalone sorts between) 
which write a Schema, then actually load the data into the created 
database. The details of this set of programs are covered below, 


IMAGE/3000 SCHEMA WRITER/LOADER 


The IMAGE Schema Writer is an interface program which reads the data 
dictionary, and primarily constructs appropriate schema definition 
Statements from the data FIELD types. The procedure will create a 
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scnema containing all tniTs of a study or only selected UNILIs 
aepending the request mace to tne front end orogram (run by Utility 
controller). 


Total output from the program includes tne completed schema ready 
for processing by DbSCHEMA.PUB.SYS, a detail load map, and oa Summary 
Or aata set load tap. The schena 1s produced py builaing tad 
internediate files - one tor tne SET part ana one for the l1Ems part 
of tne schema. As tne aata dictionary is traversed < accumulating 
all FIELOs belonging to each UNIT, the schema ITEM vart for each 
field is written (Knowing what type the FLELbD is, its size, etc.). 
At tne same time, a vosting to tne SET vart is wade for tne FIELD. 
Hach Data Pictionary UNIT is considered to pe equivalent to an IMAGE 
Data Set, so whenever a new UNIT is started in the traversal 
ooeration, the aopropriete SET definition is written, tollowea DY 
its FI@LD or item entries, The ovuffer position for the Loader 
proceaure 1S also Calculéted for eacn field in each aata set. [he 
detail load map file yenerated by the schema writer program consists 
Or a record for each Field in the data dictionary containing the 
fiela’s input buffer acdress, tne IMAGE data tyoe, tne field’s 
parent Recora Id, starting column, lengtn, and decoding information. 
nis intortiation is sufficient for later postina ot the data to the 
data base, Tne summary load map produced contains an entry for each 
data set being created, with the numoer of tields in the data set, 
tne total butter size (used for acquiring the propner size extra data 
segment in the Loager prccedure), and the name and seguence numoer 
of tne data set. 


After the Schema writer produces the Schema, Detail load mao and 
summary or data set load map, the DBSCHEMA.PUB.SYS program is 
invoked to process tne new schema(FILE equation being issued py the 
schema writer). After the root file is created, the DHUTIL.PUS.SYS 
prouram is executed, to create the new data base, Finally tne detail 
load map is sorted by Record id, then start column and the 
mMasterfile is sorted by patient id, then record date, then recorg3 
id. The Loader procedure is now ready to run. 


The Loader program reads the sorted Vetail Load map, and constructs 
a tree structure containing all information to convert/decode tror 
the masterfile records into a logical oufter to be passed to the 
[iAGE data base. The procedure also reads the Data Set loaa mab, 
and creates an extra oaata segment of proper size to act as data 
accumulation areas for each of tne Data Sets. Thre program tnen 
bedins reading the masterfile and converting/moving the data to tne 
appropriate extra data segment location. when a logical preekpoint 
in the data occurs(change of patient, or cnange of date), all extra 
data segments which have been posted, are accessed, posting their 
contents to the IMAGE data base. Various safety checks are built in 
to prevent overwriting of the extra data seqment buffers, 1.e., if a 
record member of a puffer has already peen posted, and it’s about to 
be posted again, the vnuffer is cleared first (this shoulda not happen 
normally due to tne UNIT Structure of the Data Dictionary). 


During tne loading process, pblank or missing data is noted, by 
posting a bit in a mISSING field(a_ field which is automatically 
generated for each data set) which corresponds to the sequence 
numper of tne field in the data set. This MISSING bit is to be used 
Cy various application programs accessing tne data base to ensure 
Proper statistical treatment of missing data. Each UNIT occurrence 
is also categorized into one of the ENCOUNTERS of the Dats 
Dictionary, witn the categorization being also posted to an 
ENCUUNTER field in eacn deta set(this aids in data retrieval later). 
Data wnich is to pe oecoded for reporting purposes, is decoded 
during the load operation = tne Decode table field name and field 
Value (or encode) are concatenated, then used as @a KSAM Key into the 
decodge file = retrieving the text to ve inserted into the gata base, 
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AVAILABLE RESOURCES FOR A 
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PRODUCT DESCRIPTION 


VIEW/ SOL 


IS A SOFTWARE PACKAGE THAT PROVIDES 
[WO MAJOR CAPABILITIES: 


o A SELF-CONTAINED DATA 
ENTRY SYSTEM ... 
can be implemented with no 
programming effort, and a 
FORMS SPECIFICATION UTILITY 


for drawing forms, defining 


simple and advanced editing. 


o A FRONT-END TO TRANSACTION 
PROCESSING APPLICATIONS ... 
using the FORMSPEC utility 
and an extensive library of 
high-level procedures to 
Facilitate terminal-oriented 
and user-written applications. 
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HOW DOES VIEW COMPARE TO DEL??? 


DEL anp VIEW are “NoT” COMPATIBLE 
VIEW 1S A CAPABILITIES ENHANCEMENT 
VIEW 1S NOT A PERFORMANCE ENHANCEMENT 


VIEW SHOULD BE FocUSED oN as A “NEW” DATA 
ENTRY PRODUCT “NOT” AS AN ENHANCEMENT OF DEL. 
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VIEW/3000 


"STAND-ALONE SOURCE DATA ENTRY PACKAGE” 


NO PROGRAMMING EFFORT 
FILL-IN-THE-BLANKS DESIGN 

FREE FORM DRAWING 

START ENTERING DATA IMMEDIATELY 
REFORMATTING CAPABILITY 


PRE-SET FUNCTION KEYS 
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VIEW/3000 


"FRONT-END TO TRANSACTION PROCESSING” 





COBOL, RPG, BASIC, FORTRAN AND SPL INTERFACE 


SIMPLE DESIGN, TEST, IMPLEMENTATION, AND 
MAINTENANCE 


PROGRAMMER PRODUCTIVITY INCREASES 
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VIEW/300 - main components 









U 
® 
mm 
Za 
— 

A Ah 
—~<{% 
Oo 
9 
cr 
QO. 
J 


= file | 
ig {REFORMAT 
4 reformat 





output 


, 
File 








OT*cI-d 


Key File Name [2US9 C3 Ras 





Conly if new) 


HEWLETT fi PACKARD 


1 : ‘ yl . ie + iy - Sade tty ra Ps aK Ce leas 
2 RUD PGE tee PE nee ph Tne | ey gta b en 





Tt *ct-d 


-FORMSPEC X.05.00 Main, Menu, ec aig 





tA Enter Selection 


A--Add a form 
S--Add a Save field 


G--Go to GLOBALS Menu, OR Go to form rere 





L--List Forms File, OR List form... 


D--Delete Save field ......... 
POPM 25-348:4sh08% Sees 


C--Copy new form name ....ccccncccoece 
THOM. TORM save ti eSe eee 
from Forms File Copt) ae eee 


X--Compile Forms File 
Optional: Fast Forms File 
Key File ...... 


HEWLETT | D PACKARD 






woes ae ies aginlen Neda lny F.ORM 9.5.F, 1 be Es J RD F.0 RM 





C xs, ge opcsyeng aes 
ot LD WE ab = sds roe + 











dal Oe A Bas: 


HEWLETT D PACKARD 





het ARR he ANN Bates ar TaN Sas a a er FUR MS., FLL Es 4p) RDEURM c 


Form Name 





Repeat Dption 


N--No Repeat 
A--Repeat, appending 
R--Repeat, overlaying 


Next Form 
C--Clear before Next Form 
A--Append Next Form 
F--Freeze, then append Next Form 


Nam e C $ H E AD.... tot nlf Lp Ete 8 id J 





Comments 





(Purchase. Or der..:.F OF Miso. itegs cats ce het nade OBEYS. Meee wee oy 
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* # # ENTER A NEW PURCHASE ORDER *# @ » 


DATE: [date ] 
SHIP TO: {name J 
Caddri J 
Caddre } ZIP (zip 1] 
ORDER # QTY. PART # PRICE 


Cordernum ] (qty ] Cpartnum } Cprice ] 


pt°cil-d 


HEWLETT fy PACKARD 






4 eo. Fa 


» * # ENTER 


DATE: (date ] 
aA 
Name ' Diype Gime 
kab iia 627 ne ARR ODE sete i Tena CS OS he eR 





### Processing Specifications a+ 


INIT 
SET TO $TODAY 


FIELD 
IN '1/1/78% : !1/1/79! “Must be a valid date in 1978" 
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Comprehensive 
Data Editing & Formatting 


High-level language for editing/formatting 
specification: 


oo 


cI 


MW W@W OM OH 


Length check 

Range check 

Table check 
Comparison for < = > 
Justify 

Fill 


Arithmetic expressions 


ee 


Pattern match 


Field moves 


Logical/conditional 
(if-then-else) 


Modulus 10/11 
check digits 


Custom error messages 
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INIT 


FIELD 


FINISH 
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PHASES 


PERFORMS STATEMENTS DURING THE INITIALIZATION PHASE, 
FOR EXAMPLE: SET TO 100.00 


PERFORMS THE STATEMENTS DURING THE FIELD PHASE UNTIL 


DATA IS ERROR FREE. 
FOR EXAMPLE: IN 20:200; IF IN 100:200 THEN JUSTIFY RIGHT 


PERFORMS STATEMENTS DURING THE WRAP-UP, 
FOR EXAMPLE: SET TO SFIELD1; CHANGE NFROM TO $END 
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FORMSPEC..%.05:,00 Main, Menu 
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> oo e rt . ree ‘ s . vo¢ ge sis o 
a we et 4 iat er) Seer ee, Sei avie eon Might A he ed 


CX.) Enter Selection 


A--Add a form 
S--Add a Save field 
G--Go to GLOBALS Menu, OR Go to form (Gam 


L--List Forms File, OR List form ... (xD) 
D--Delete Save field ......... 
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C--Copy new FOrM NAME «64:5 ees dees Sars 
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from Forms File Copt) ...... 
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X--Compile Forms File 
Optional: Fast Forms File { coe < 
Key File ...... [RpvORe ere, Conly if new) 
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Friendly, Ready-To-Run 
Data Entry Program 





“ Provides standard data entry features via 
special function keys 


e “Browse” through already entered data 
e Modify and/or delete already entered data 


e Resume to prior point of data collection 


= Allows immediate execution of data entry 
formats and editing without use of compilers 


m™ Stores data records in MPE sequential files 
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:RUN ENTRY.PUB.SYS 
HP32209X.05.00 ENTRY CC) HEWLETT-PACKARD CO. 1978 


Enter Forms File name and press RETURN: ORDF ORM 
Enter Batch File name and press RETURN: BATCHFL 
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SHIP TO: 


ORDER # 
Cordernum ] 


HEWLETT ID PACKARD 


ENTER A NEW PURCHASE ORDER # # » 


DATE: {(date ] 
[name ] 
Caddr1 ] 
faddre } ZIP (zip 1] 
QTY. PART # PRICE 


Cqty ] Cpartnum ] (price ] 
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ORDER # 
LPO-22310 





ENTRY... x ra) =) ¢ 00 


SHIP TO: 


5 J 


ENTER A NEW PURCHASE ORDER * * *# 


DATE: 


(APEX Manufacturing CO, 
(21019 Main Street 
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Le, aiyegybateh Record.#1 
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QTY. PART # 
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USER-WRITTEN PROGRAMS 


INTERFACES WITH 5 LANGUAGES: RPG, COBOL, FORTRAN, BASIC, SPL. 


MANAGES INTERFACE BETWEEN PROGRAM AND TERMINAL, FORMS FILE, AND 
ENTERED DATA, 


PHYSICAL ORDER OR LOCATION OF THE DATA FIELDS ON THE SCREEN IS 
IRRELEVANT TO THE APPLICATION PROGRAM, 
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VIEW/3000 INTRINSICS 





VSHOWFORM 
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Ld e 
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VOPENTERM 
VCLOSETERM 


VREADFIELDS 


VOPENBATCH 
VCLOSEBATCH 





VWRITEBATCH 
VREADBATCH 
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VGETNEXTFORM 


& 


FORM DEFINITION 


MSG 
VOPENFORMF 


ENH VCLOSEFORMF 






VSETERROR 


) 2) iden 


VFIELDEDITS 


VERRMSG 


VINITFORM 


VFINISHFORM 
VGETF., .——hk 


<—~ VPUTF... 
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XGETBUFFER 
XPUTBUFFER 
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VIEW/3000 - main components 
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forms 


file 





INTRINSICS 
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batch 
file 
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REFORMAT 





4 reformat 


output 
file 
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Flexible Reformaiting Utility 


A separate batch program to: 
i Meet data format requirements of existing programs 
Fi Perform batch-type formatting 
e Combine data from several forms into a single record 
e Split data from a single form into two or more records 
e Rearrange data within a record 
e Adjust data within a field (e.g., “justify” or ‘‘fill’’) 


REFSPEC 
PROGRAM 





REFORMAT. 
TING 
SPECS 
REFORMAT 
—————> PROGRAIA ————D OUTPUT FILE 
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REFSPEU X.05.00 Main Menu... on. cues 


Enter Selection 


A--Add a reformat 
X--Compile Reformat File 
G--Go to GLOBALS Menu 
F--Go to FORMS FILE Menu 


G--Go to reformat _id 
L--List reformat id 
D--Delete 
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output field 


reformat id 
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REFSPEC 4.05.00 Globals, Menu.. 





Output Record Format [o@ 


F--Fixed length records 
V--Variable length records 
U--Undefined length records 


Record Length (bytes) 


Upshift? [ae Yes/No 
Convert to EBCDIC? [gpP Yes/No 





Record Terminator String 


Field Separator String 
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Forms in Input Sequence: 
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TREFSPEG..X.05.00 Output, Record Menteiis cura, 


Field Name 


DATE 
NAME 
ADDRe 
DATE 
ORDERNUM 
PARTNUM 
QTY 
PRICE 





INPUT DUTPUT 
Substring Form Name Field Name Strt Len Strt 
Strt Len Col Rec 
2 
20 
DATE1 2 
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CREFSPEC,. 4405.00 Output Field Menu: .... 





veces REF ORMAT.LDENTLELER 3 9H LEU 


INPUT Field: SC Start: Length: Form: 


OUTPUT Field: ([S]}spereecseucess 2 Data Type: Gi 
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STRIP All Leading Trailing 








INSERT CHECK DIGIT 10/11 


JUSTIFY SIGN PLUS SIGN? Y/N 
L--Left F--Float 
R--Right _--Left 
C--Center R--Right 
Z--Zoned 
N--No sign 


FILL All Leading Trailing 
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REFORMAT 





SPEC FILE 
<i. 
BATCH 
FILE ey 


OUTPUT 


REFORMAT 
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REFORMATTED 
FILE DATA-- 


PRINTS 
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Summary 


EY What is it? 


e Stand-alone source data entry 
e Front-end to transaction processing systems 


El Major features! 


Simple forms design 
Comprehensive editing 
Data entry without programming 
Reformatting to meet existing requirements 
Adaptable language interface 

(BASIC, COBOL, FORTRAN, RPG, SPL) 
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FACTORY DATA COLLECTION 


by 


LINDA SIENER 
HEWLETT-PACKARD COMPANY 
DATA SYSTEMS DIVISION 


One of the most challenging aspects of manufacturing control is the collection 
of timely and accurate factory data. The quality of this data largely determines 
the effectiveness of today's modern control systems. Late or inaccurate data can 
only produce low quality information. Timely shop information is, therefore, essen- 
tial to the control of manufacturing processes. This same information is also import- 
ant to the accountability of direct labor records in the financial system. 


Typically, the shop floor environment is the most difficult area from which to 
extract information. The factory workers are primarily concerned with manufacturing 
items and accurately reporting their work is incidental to their job. What is needed 
is a factory data collection system that can help make the data collected from the 
workers more accurate and timely and, at the same time, easily blend into the cur- 
rent operating methodology. 


Advances in electronic technology have now made it possible to cost-effectively 
introduce factory data collection terminals directly into the manufacturing area. 
No longer does data have to be written down, keypunched, checked for accuracy and 
corrected days after it was written down. By using the factory data collection ter- 
minals, the data can be collected and validated at its source, i.e., the factory 
worker. But what about the major programming effort necessary to monitor al] these 
factory data collection terminals as well as validate the data as it is entered? And 
once that is done, how about the task of maintaining these programs? As everyone 
involved in designing or implementing computer systems knows, the cost of software 
is steadily increasing and the trend in industry is toward application packages. 
Because of this, Hewlett-Packard offers Datacap/1000, on the HP 1000, which assists 
the programmer in quickly and easily implementing data collection with these factory 
data collection terminals. Also, Datacap makes modification to the data collection 
system very simple. Datacap helps meet the challenge of collecting timely and accu-- 
rate data in the factory. 
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ASK / 3000 


THE NECESSARY COMPLEMENT TO IMAGE/QUERY 


- ASK/3000 may access and report any information from 
an IMAGE/3000 data base 


- Like QUERY, it enables you to: 
-~read,add,modify,delete information 
-select entries 
-generate reports 
but almost every limitation you have met using QUERY 


has disappeared ! 
- With ASK/3000 you can: 
-FIND and REPORT items from different data-sets 
“Access sub-items in any command 


-Call user procedures for solving a problem that 
cannot be solved with standard parameters 


-Use new report statements as IF, TRAILER or exis- 
ting statements with greater capacities as HEADER 


DETAIL... 


-Use registers associated to Detail, Group or 


Total statements to perform any calculation 
-Call ASK/3000 from a user program 


mEtc..ee 
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COGELOG 


QUESTIONS AND ANSWERS ON....ASK/3000. 


Is ASK COMPATIBLE WITH QUERY ? 
ee ee = ee 


Yes, all reports written with QUERY may be run with ASK 
without any modification. 


IS IT POSSIBLE TO SELECT RECORDS FROM A DETAIL DATA SET ACCORDING 
TO THE VALUE OF AN ITEM LOCATED IN A MASTER ? 
EE EEE LN A MAS IER 


Yes. The FIND command accepts multidata set criterions and this is 
true for any type of data set. 


IS ASK HANDLING SUB-ITEMS ? 
eee 


Yes. ASK allows you to write and modify sub-items. In all commands 
a sub-item may replace an item. 


MAY I SELECT RECORDS ON THE VALUE OF THE FIRST CHARACTER OF AN ITEM ? 
a nS CHARALLER OF AN ITEM 


Yes. You can mask any non significant character by a "\" and select 
records on the value of the other; 
example : FIND NUMBER = "\2\3\\° 


CAN ASK SORT ON THE FIRST CHARACTER OF AN ITEM ? 
—— a EER ER OF AN LITEM 


Yes. Sorts can be performed on any substring inside an item 
(or sub-item). Overlapped keys are allowed. 


MAY I REPORT ITEMS FROM DIFFERENT DATA SETS Z 
EE EERE VATA OBL 


Yes. You only have to specify to which data set belongs the desired 
item. 


IF A PROBLEM CANNOT BE SOLVED BY ASK/3000 , AM I OBLIGED TO RE-WRITE 
THE WHOLE REPORT IN STANDARD PROGRAMMING ? 
——————$—$—$ BEAR ERUGRAMMING 


No. You can write a user procedure and call it in any HEADER,TRAILER, 
DETAIL, GROUP, or TOTAL statement. 


MAY I EXECUTE CONDITIONALLY A REPORT STATEMENT ? 
EE ES REY DOLALEMENT 


Yes. A new statement "IF" enables you to manage flags. Any report 


statement can be conditionally executed according to one of these 
flags. 
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9. CAN ASK BE CALLED FROM A USER PROGRAM ? 


Yes, You can use ASK's functions in your own program by creating an 
ASK process, and sending to it the name of an XEQ-file to be executed. 


10.MAY I SAVE A VALUE COMPUTED IN A REPORT ? 


Yes, You can use the UPDATE function in a register statement to store 
a register content in an item. For any other storage, you have to 
write a user procedure. 


11.1F SUCCESSIVE REPORTS NEED THE SAME SORTS ON THE SAME DATA SET, 
CAN ASK SORT THIS SET ONLY ONCE ? 


Yes. ASK keeps sort parameters in the select file, and the select-file 
can be saved as permanent. 


ASK knows when it has to perform the sort or not. 


12.WHAT ELSE CAN I DO WITH ASK ? 
Many things, such as : 


- ROUND results of divisions in packed decimal format. 

. Print dates in EUROPEAN format. 

. Prevent DETAIL, GROUP, TOTAL lines to be spread on 2 pages. 
- Manage ASK output files. 

. Generate TRAILER lines at bottom of pages. 

. Execute registers functions only in GROUP or TOTAL lines. 

. Send messages to the operator. 

s “BUC« 6% 


Moreover, you can use ASK as a frame for any batch program, by 
writing a pseudo-report containing sorts, and register statements. 
You only have to write the code of your application as user 
procedures. 


You will find a summary of ASK capabilities and a detailed example 
in the next pages. 


This example is a typical supplier accounting report. You will find 
a schema of the data-base, the text of the report and the listing 
generated by ASK. 
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13.HOW CAN I BUY ASK ? 


First, you can get more information about ASK.If you request it, 
we will send you free of charge, the reference manual and/or a 
demo tape (valid two months) to test it on your own site. 


14.WHEN CAN I GET ASK ? 


ASK is immediately orderable from : COGELOG 


l1 res des Quinconces 
91190 GIF SUR YVETTR 
FRANCE 


15.HOW IS ASK MAINTAINED ? 
ee eee Ne 


If you happen to find a bug in ASK, send us a detailed "bug-report". 
When the bug is corrected, every ASK installation will receive 
a new tape to load on its system. Moreover, a "bug-status-report" 


will be sent periodically with temporary turn-arounds for yet 
uncorrected bugs. 


16.WHAT WILL HAPPEN IF H.P., MODIFIES ITS SOFTWARE ? 
et tt SOFTWARE 


ASK is an SPL-written application program which directly calls 
IMAGE intrinsics (like any of your data-base application programs) . 
More than 700 sites use the IMAGER subsystem all over the world. 
This is why HP CANNOT modify IMAGE external specifications. 
Therefore; ASK will run as long as IMAGE does, 
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### DATA BASE SCHEMA EXAMPLE ##*# 


SCONTROL NOLISTs,ERPORS=2, TABLE 
STITLE "DATA BASE DEFINITION" 
<< 

##% DATA BASE SCHEMA 
2? 
BEGIN DATA BASE SB; 


PASSWORDS: 


4 COMPTA; 
S FOURNI; 


ITEMS: 


wy) 


<< ACCOUNTING N T R 


DAY P) 11 (/4) 3 
MONTH, Ii (/4) ; 
YEAR Ii (/4) ;3 
NENTRY,» 11 (/4) ; 
VALUE, Pi2 (74) 3; 
COMMENT, U16 (7/4) ; 


<< SUPPLIER S >> 


% tt & 


Ie §& >> 


<< ENTRY DAY >> 

<< ENTRY MONTH >> 
<< ENTRY YEAR >> 
<< ENTRY NUMBER >> 
<< ENTRY VALUE >> 
<< COMMENT >> 


NSUPP , U6 $3 << SUPPLIER NUMBER >> 
SNAME , U34 3 << SUPPLIER NAME >> 
STREET, U34 3 << STREET NAME AND NUMBER >> 
ZIPCODE , U34 3 << ZIPCODE AND CITY NAME >> 
SPAGE 
SETS: 
<< 
*# MSUPP ; SUPPLIER MAS TER 
>> 


NAME: MSUPP,AUTOMATIC (/5)3 


ENTRY: 


NSUPP(1); << SUPPLIER NUMBER >> 


CAPACITY: 1011; 


<< 





>> 
NAMES DECRM,-DETAIL (445/475) 3; 


ENTRY: 
DAY, 


qm Ei aE ele Ga EE Gr aap e- ee oP Sy SE a we Ge CE Cte Oe ee ee ee Oe Ge Gee EE oe CG GE EP GE GE Coie GOED GME Gare eee GE) Gee 
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_ 


Cee DATA FASBEK SCHEMA EXAMPLE oo CUNT « « 


MONTH, << ENTRY MONTH >> 
YEAR, << ENTRY YEAR >> 
NSUPP, << SUPPLIEK NUMBER >> 
NENTRY, << ENTRY NUMBER >> 
COMMENT, << COMMENT >> 
VALUE, << ENTRY VALUE >> 

CAPACITY: 2500; 

<< 

#* DSUPP : SUPPLIER DETAIL 

>> 


NAMES DSUPP,DETAIL (4,5/4,5)3; << SUPPLIER DETAIL >> 


ENTRY: 
NSUPP(MSUPP), 
SNAME, 
STREET, 
ZIPCODE, 


CAPACITY: 550; 
END, 
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##e KEPORT SOURCE EXAMPLE ### 


REPORT 
SCT TS Te TS TTT PTET TTS PPC CP CCST SS ST ESTE TS he eile 
* SUPPLIERS ACCOUNTING PEPORT * 


SERGE EE EERE EEEREERE EERE EREREEEEHHEERETHHHE HEHEHE HEE EE 
* OUTPUT CONTROL WORDS 

e eweeseseseerereevcecoceos 

LINES=56 

EUROPE 

NOSPLITGROUP 

NOSPLITTOTAL 

DYNAMICTRAILER 

OUT=LP,"MOUNT SUPPLIER FORM ON LP PLS," 

* 


# MEANING OF REGISTERS: 

%X wswewwewewwnwvnwewrowaowvere Ze 

* R1 3: SUB TOTAL FOR EACH SUPPLIER 
# R2 : GENERAL TOTAL 

Sd 


* PERMANENT HEADER 

*°FULLDATE’ IS AN USER PROCEDURE THAT PRINTS THE MONTH Ih FULL LETTERS 
% 

Hi,PAGENO,69,SPACE Ai 

Hi," PAGE*NUMBER",65 

H2,"SUPPLIERS ENTRIES ° PAGE",65 
H2,FULLDATE(65) +X | 

H3,48("="),65 

% 

* CONDITIONAL HEADER : THESE STATEMENTS ARE THE SAME AS 
# THE GROUP STATEMENTS, THEY REPEAT THE GROUP LINES IF A 
# PAGE EJECT OCCURS BETWEEN A GROUP AND A TOTAL STATEMENT 
# 

H4,68("="),69,SPACE Bi,1IF F4 

H5,"1 SUPP #@# $& NAME ¢; ",30,1IF F4 
HS,NSUPP,18,IF F4 

H5,DSUPP,.SNAME,66,IF F4 

H5,"I",69,I1F F4 

H6, "1 ADDRESS : ",30,/I1F F4 

H6,"1",69,I1F F4 

H6,DSUPP.STREET,66,1F F4 

H7,"1",2,1F F4 

H7,"I",69,1F F4 

H7,DSUPP.ZIPCODE,66,I1F F4 

H9,68("%-"),69,1F F4 

H1i0,"I DATE I COMMENT I",35,1F F4 

Hi0," DEBIT I CREDIT I",69,IF F4 
H11,68("2"),69,IF F4 

# 

* GROUP: BEGINNING OF FRAME 

+ 

G28,68("=-"),69-SPACE Bl 


G27,"1 SUPP # & NAME ¢ ",30 
G27,NSUPP,18 

G27,DSUPP.SNAME, 66 

G27,"1",69 

G26,"I ADDRESS 3: ",30 


G26,"1I",69 
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### REPORT SOURCE EXAMPLE #**# CONT coe 


G26,DSUPP.STREET, 66 

G25,"I"-2 

G25,"1",69 

G25,DSUPF.ZIPCODE,66 

G23,68("="),69 

G22,"I DATE I COMMENT I1*,35 
G22," DEBIT J CREDIT I",69 
G21,68("="),69 

G21,SET F4 

# 

Si,DAY 

S2,NSUPP 

S3, DSUPP.ZIPCODE 


# 


Fs 


MEANING OF THE FLAGS: 


* F1 : SET = POSITIVE VALUE, CLEAR = NEGATIVE VALUE 

# F2 : SET = POSITIVE SUB-TOTAL, CLEAR = NEGATIVE SUB-TOTAL 
+ F3 : SET = POS, GENERAL TOTAL, CLEAR = NEG, GENERAL TOTAL 
# F4 : SET = BETWEEN GROUP/TOTAL, CLEAR = NOT BETWEEN 


*% 


IF,VALUE > "0" THEN SET F1 ELSE CLEAR Fil 
IF,R1 > "0" THEN SET F2 ELSE CLEAR F2 

IF,R2 > "O" THEN SET F3 ELSE CLEAR F3 

Di,"I 4 7/78 I",13 

Di,"I I I",69 
Di,DAY ,5 

Di,MONTH,8 

D1,COMMENT, 31 

Di, VALUE,67,E1,IF NOT Fi 

Di, VALUE,50,E1,1F Fi 

R1,ADD, VALUE 

R2,ADN,R1-T2 

% 

* SUB-TOTAL ,.-END OF FRAME 

* 

T20,68("-"),69 

T21,-R1,67,/E1,-IF NOT F2 

T21,Ri1,50,E),I1F F2 

T21,"I BALANCE <6. %080se%0%000008% 85> 
T21/-"1I",69 

T22,68("-"),69 

T22,CLEAR F4 

T2,R1 

* 

* TRAILER: THIS STATEMENT CLOSES A FRAME IF A PAGE EJECT OCCURS 
% BETWEEN A GROUP AND A TOTAL 


+ 
Z1e68("=-"),69,I1F F4 


* GENERAL TOTAL 

# 

TFie"TOTAL BALANCE ccceccccvcevces "*e 36e5PACE B2 
TF1,R2,67,E1,1F NOT F3 

TF1,R2,50,E1,1F F3 

E1,"Z2ZZ,Z222,229.99" 

END, 
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### USER PROCEDURE EXAMPLE ##+# 


!JOB JOBUSER, USER,GROUP 
!SPL,USLUSER 
SCONTROL SUBPROGRAM, SEGMENT=USER,LIST,ADR 
BEGIN 
<< 
THIS PROCEDURE PRINTS THE CURRENT DATE IN FULL LETTERS 
THE PRINT POSITION IS PASSED THROUGH THE OPTIONAL PARAMETER ° 
>> 
PROCEDURE FULLDATE (DBNAME, ISORT, LINEBUF » REGISTERS, STORAGE, FLAGS, PARAM) } 
INTEGER ARRAY DBNAME, ISORT,LINEBUF,REGISTERS, STORAGE; 
LOGICAL ARRAY FLAGS; 
INTEGER PARAM} 


BEGIN 
INTEGER N,DsINDEX,DAY, YEAR; 


BYTE ARRAY QUTPUT(#) = 
INTEGER ARRAY MONTH‘’TA 
INTEGER ARRAY M1(#) 


LINEBUF: 
BLE(COsi1): 
MONTH’ TABLE, 


M2(#) = 


MONTH’ TABLE(1), 


M3(*) = MONTH’ TABLE(2), M4(#) = MONTH’ TABLE(3), 
MS(*) = MONTH’ TABLE(4), M6(*#) = MONTH’ TABLE(S), 
M7(0*#) = MONTH’TABLE(6), M8(#) = MONTH’ TABLE(7), 
M9(#) = MONTH*TABLE(8), M10(#) = HONTH’TABLE(9), 
M11¢0#) = MONTH’ TABLE(10), M12(#) = MONTH’ TABLE(11);3 
BYTE ARRAY STRING(02107) = PB := " JANUARY"," FEBRUARY", " 
" APRIL"," MAY", " JUNE", * JULY"," 
"SEPTEMBER"," OQOCTOBER"," NOVEMBER"," DECEMBER": 
INTRINSIC ASCII,CALENDAR; 
M13=M33=M52=N73=M83=M103=M123=31; <<INIT. MONT’ TABLE>> 
M43=M63=M9$3=M11:=303 
D := CALENDAR; 
DAY s= D.(739);3 
YEAR $s D.(0s7): 
IF YEAR/4#4 = YEAR THEN M2 := 29 ELSE M2 s:= 28; 
INDEX := 03 
DO BEGIN 
N s= MONTH’ TABLECINDEX) 3 


IF DAY=N < Q THEN GOTO MONTH’ FOUND; 


DAY := DAY - N; 
INDEX s:= INDEX + 13 
END UNTIL INDEX = 123 
RETURN; 
MONTH’FOUNDS 
MOVE OUTPUTCPARAM#=15) 3= STRINGCINDEX#9),(9),23 
MOVE *# s= " 19%3 
ASCIICYEAR,10,QUTPUT(PARAM=2))3 
END; 
END, 
!SEGMENTER 
SL SL 


PURGESL SEGMENT,USER 
USL USLUSER 

ADDSL USER, PMAP 

EXIT 

SEOJ 
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### REPORT EXAMPLE ### 


: PAGE©NUMBER 

SUPPLIERS ENTRIES : OCTOBER 1978 
I SUPP #3 190399 NAME > PUB SHARK 1 
I ADDRESS : 37 RUE DE LA REPUBLIQUE I 
I 54140 JARVILLE MALGRANGE I 
i DATE I COMMENT | I DEBIT I CREDIT I 
I 21/10/78 I RECRUTEMENT I I 228.00 I 
I 22/10/78 J. RECRUTEMENT I 228.00 1 I 
I BALANCE <6 se -e:soce-e0e © oe ee 0,00 I 
I SUPP #: 200099 NAME : TRANSWORLD I 
I ADDRESS : 17 RUE CHILDEBERT ] 
I 69002 LYON I 
I DATE I COMMENT I DEBIT l CREDIT l 
1 19/10/78 I 78/TH/08/129/Z2°~—so 334,40 1 I 
1 22/10/78 1 78/TH/08/129/2Z I I 2,234.40 1 
I 22/10/78 1 78/TH/08/129/2 I 1,900.00 I I 
I BALANCE £44:4-0¢.6%d.6s0@e eee! 0,00 I 
I SUPP #: 2008 NAME :  JOuO INC I 
I ADDRESS : 1 RUE DE LA GRANDE TRUANDERIE I 
I 75004 PARIS I 
J DATE I COMMENT I DEBIT I CREDIT I 
I 22/10/78 1 POT DE VIN I 4,380.05 I I 
1 22/10/78 I 11024 I I 29,396.41 I 
I 25/10/78 1 11024 I 25,016.36 I I 
I BALANCE 66 66% 6 6820 bee eew! 0.00 I 
I SUPP #: 1908 NAME : VENUS AND SONS I 
I ADDRESS : 16 RUE FERRUS I 
I 75014 PARIS I 
I DATE I COMMENT I DEBIT I CREDIT I 
I 12/10/78 1 TEST} I 13,00 I I 
I 13/10/78 1 TEST2 I 3,00 1 I 
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a## REPOPT EXAMPLE *### CONT 2. 


PAGE=NUMBER 2 


SUPPLIERS ENTRIES : OCTOBER 78 

I SUPP #: 1908 NAME :  VEKUS AND SONS I 
I ADDRESS : 16 RUE FERRUS I 
I 75014 PARIS I 
I DATE 1 COMMENT © I DEBIT I CREDIT I 
1 13/10/78 1 TEST3 I 2.00 I ] 
1 14/10/78 I TEST4 I 1,00 1 I 
1 17/10/78 I. TESTS I 105.00 1 I 
1 18/10/78 I 460178 I 3,785.76 1 I 
1 19/10/78 I 460178 I I 3,785.76 1 
i BALANCE, ccccscvceseveces 124,00 J 
1 SUPP #: 180199 NAME : BILLY THE KID BANK I 
I ADDRESS : 37 RUE DE VAUVENARGUES l 
I 75018 PARIS I 
1 DATE I COMMENT J DEBIT I CREDIT I 
I 22/10/78 I 1496/78 I 14,736. 84 1 I 
I 22/10/78 I 1496/78 I 2,593.68 1 I 
I 22/10/78 I 1496/78 I 1 17,330.52 I 
I BAI ANCE, eee 8 e888 @ eeeo0np e008 @ 0,00 I 
I SUPP #3 1909 NAME > OUT OF SPACE I 
I ADDRESS : 23 AVENUE DU CHATEAU I 
l 78000 VERSAILLES I 
1 DATE I COMMENT 1 DEBIT I CREDIT I 
1 22/10/78 I 37021 I 6.58 1 I 
1 22/10/78 I 37021 I I 44,00 1 
1 22/10/78 I 37021 I 37.42 1 ] 
1 BALANCE. eeeeet @ ®@ esvescv0e906 0,00 I 


TOTAL BALANCE Terr eee eee ee 124.00 
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ABSTKACT: The format and management of USL and PRUGRAMN files 
under the MPE III operating system, running on Hewiett 
Packard 3000/11 and 3000/I]II computer systems, are presented 
in this paper. LSL files are used to store relocatable 
binary modules, and PRUGKAM files to store fully prepared 
programs. Tne presentation 1s aimed at programmers 
implementing compilers on xAP30U0 systems. ‘The reaaer is 
assumed to pe familiar with the architecture oft tnese 
systems, and to understand basic concepts'7 of relocatable 
code, link editing, and so on. The scope of tne presentation 
is intended to provide tne reader an aaequate pbacKground wlth 
whicn to successfully pursue a compiler-writing project. 
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le Introduction 


1.1. Overview 


All operating systems adopt conventions concerning the 
formats of object code files. Inese files must be in 
correct formats tO be processed by system segmenters, 
linkage euitors, and loaders. Tne MPE operating system 
defines four types, or forinatS, Of object code files, as 
follows: user subprogram libraries (USL’S), relocatable 
libraries (RL’s), segmented libraries (SL°S), and program 
files (PROGRAM’S). Of these, RL’s and SL’sS have rather 
specialized uses, and their formats are of little interest 
to the compiler writer. The formats of USL and PROGRAM 
files, on the other hand, are of great interest. If a 
compiler is to produce absolute code, it wili generate 
PROGRAM files. If it is to produce relocatable code, it 
will generate USL files. 


This paper presents an Overview of the formats of USL and 
PROGRAM file formats used py mPE III, on HP300U/I1 and 
HP300U/TII computer systems. It is neither exnaustive nor 
scrupulously detailed. Readers with some experience in 
object code formats will not tind it ditficult to fill in 
aetails not included here py examining USL and PROGRAM 
files. 


A word of caution to the reader is appropriate at this 
point. Hewlett Packard is uncooperative, and seems quite 
indifferent to the needs of its users to unagerstana MPE 


conventions. Because of this, all the information in this 
paper nad to be deduced from examination of USL and PROGRAM 
files. In consequence, although the author believes the 


information included here to be fully accurate as of tne 
date of this writing, the reader should Keep in mind that it 
may nonetheless incluoce some errors. For the most part, 
though, it may be used with confidence, Tne author has 
written a compiler which generates USL files based on 
section three of thisS paper, and a PROGRAM file decompiler 
based on section two. Both are operating satisfactorily. 


1.2. Conventions 


A numvoer of conventions are adopted to enable concise 
explanations and illustrations. These conventions are 
applied consistently, but occassional, well-marked 
aeviations do occur. The conventions are as follows: 
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SPL/ 3000 notation ls used in all cases’ where 
illustrative code is provided, 


"P" represents a variable of tyne integer pointer. in 
all taples, illustrations, and examples it 1S assumed 
to point to the first word of the entity under 
discussion. 


In the case of sinyle bit fields, "i" is the "on" 
state, ana "0" is the "oft" state. Similarly, the on 
State 1s the true state, ana tne off state is tne 
false state. 


wames in PROGRAM and USL files, such as procedure or 
segment names, are@ a variable number of words in 
length. The first byte ot a name is always in the 
Pe(Si3) field, tne length of tne name in bytes in 
P.(4:4), and various context=dependent information in 
P.(034). The name continues in as many consecutive 
bytes as needed, beginning with P.(8:8). A name tield 
is always an integral number of words in length. ne 
last byte is thus wasted if tne name is an even number 
of pytes long. In illustrations, tne P.(0:s) tield 
Will be diagrammed explicitly, but the remainder of 
the name will be shown simply as a large undivided 
area. The reader should Keep in mina that this 
represents a variable length field. In the text of the 
paper, this entire group of fields is referred to as a 
"name field," and tne various parts are not 
explicitly mentioned unless necessary. for tne 
discussion. 


In illustrations, when a word is divided, unless 
indicated otherwise, it is divided into bytes, or into 
nipbles. Because of this, no explicit bit tiela 
indications are given in illustrations for byte or 
nibble alignea fields. 
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2- PROGKAM files 


Tne loader in MPE processes PROGRAM files. In a program 
tile, all relocatable references nave been resolvea, global 
storage laid out and initialized, and seymentation 
completed. Tne only linx editing remaining to be done is to 
establisn linkages with external program units to ove found 
in SL’S. This last linking step involves only the 
completion of seqment transfer tapnles. Particular STT 
entries nave already been assigned to particular externals, 
so no relocation per se need be performed at load time. 


PROGKAM files nave the following file characteristics: 
o Ineir record length 1s 128 words. 
o Tney are identified by a file coae of 1029. 


o tne file length is petween 4 and 3272/7 records, 
inclusive 


o The records are tixed length, binary, without carriage 
control. 


o Tne file consists of only a single extent. 
All tnese restrictions are imposed by the MPE segmenter and 


loader. Other file configurations are not acceptaple. 


2e1-e Contents of PROGRAM files 


A program tile 1s logically divided into five parts, each of 
which must begin ona record boundary. The parts are as 
follows: 


1. A "tixed area" containing pointers to the rest of 
the file, and other miscellaneous information 


2~ An image of the initial global DB area for the 
program, already fully initialized 


3. The code segments comprising the program 
4. A list of externals referenced by the program 


5. A list of entry points to the program, 
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Inese five parts will occur in a PROGRAM tile in tne oraer 
listed. If a program uses no global DB storage, the glopnal 
DB area part of tne tile will be omitted. Since all tive 
parts of program files negin on record voundaries, record 
addresses are used throughout tne file for indicating tne 
location of needega intormation. All record aodresses used 
in program files are Single word inteugers. 


2e2- The fixea area 


the fixed area occupies the first one or two records of tne 
file. The length oft the area, one or two records, depends on 
whether or not all the intormation to pe incluaed in the 
area fits ina single record. It will always tit in two. 
Table 2.2A lists the contents of the fixed area in order. 


Table 2.2A -=- Fixed Area Contents 


Fiela Contents 

P.(031) program contains fatal error 

P.(131) program contains non-fatal error 

P.(231) zero the Db area prior to starting 
execution of the program 

P.(331) program contains at least one 
privileged segment 

P.(432) (use undetermined, only zero opserved) 

P.(631) program nas NS capapvility 

Pe(7s1) program has BA Capability 

P.(831) program nas IA capability 

P.(931) program has PM capability 

P.(1031) program has CR capability 

P.(1i3:i1) program has RT capability 
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Table 2.2A \e2- Fixed Area Contents (cont.) 


Fiela 


P.(12:1) 
P.(13:1) 
P.(1431) 
P.(15:1) 
P(1) 


P(2) 


P(3) 


P(4) 


P(5) 


P(6) 


P(7) 


P(3) 


P(9) 


P(10) 


P(11) 


P(12) 


Contents 


program has MR Capability 
(use undetermined, only zero oposerved) 
program has DS capapility 
program has PH capability 
the number of segments in the program 


the number of words in the global DB 
area of the program’s run-time stack 


beginning record number of the image of 
the global DB area of the stack (should 
be ignored if P(2)=0) 


beginning record number of the segments 
list 


the initial stack size ("s3:STACK=" of 
prep command) 


the initial DL size (";DL=" of prep 
command, zero if ";DL=" not specified) 


the maxdata specification (“;MAXDATA=" 
of prep command, -1 if "?;MAXDATA=" not 
specified) 


beginning record number of entry points 
list 


logical segment number of the entry 
points to the program 


PB relative address of primary entry 
point 


execution time DB relative address of a 
table used by TRACE/3000 (#1 if table 
not used) 


execution time DB relative address of 
the .FORTRAN logical units table, the 
FLUT (-1 if FLUT not used) 


Taple 2.2A -- Fixed Area Contents (cont.) 


P(13) beginning record number of the 
externals list 


P(14) STI number of primary entry point 
P(15) execution time DB relative address of 


TRAPCUM’, a common block used for 
interfacing to user trap routines 


P(16) tnese locations have been ovnserved only 
to with the value zeroe-they are probably 
P(27) reserved, and should always be zero 


Following P(2/) are two variable Length subareas of the 
fixed area. The first begins in P(28), and is P(1) bytes 
in Length. That is, there is one byte for each segment in 
the program. This subarea is always an integral number of 
words in length, so a byte is sometimes wasted on the end. 
ft is pelieved tnat the loader uses tnis subarea for 
mapping logical segments to actual segments. After a 
program has been prepared, but before it has ever been 
loaded, tnis Subarea will contain all zeros, 


The second subarea begins in the word immediately following 
the last word of the first subarea. The second subarea 
includes a one-word segment descriptor for each segment in 
the program. These segment descriptors are in the same 
Order as tne segments tnemselves in the file. The tormat 
of a segment descriptor is given in table 2.2B. 


Table 2.2B -- Segment Descriptor Format 


Field Contents 
Ps (021) segment is privileged 
Pe(isi) Cuse undetermined, only zero observed) 
P.(2:2:14) the length of the segment, in words 
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2e-3- fhe global DB part 


The global DB part is simply an image of all DB and 
secondary DB which is to be allocated when the program 
beyins execution. AS many recoras as necessary are used to 
nold the needed number of words. Unused words at tne end 
of the last record, if any, are ignored. I[f the number of 
words of DB is given in the fixed area as zero, then this 
area may be omitted from the file altogether, and the 
record pointer to this area in the fixed area may be set to 
one (one is the only value tor this pointer yet observed in 
this context). 


Tnis DB area image is fully initialized. It includes 
TRACE/3000 tables, the FLUT table, common blocks, DB and 
secondary DB arrays and simple variables, and anything else 
whicn must be placed in the DB area. There is no 
opportunity to add to the DB global area once the program 
pegins execution, since it will pe delimited py Ds and the 
initial Q register setting. Allowance must be made for all 
global run-time storage at the time the PROGRAM file is 
generated. 


Lede The segments list 


The code segments which comprise the program are placed, 
one after another, in the segments list. Eacn segment 
pegins on ae record boundary, and occupies’) an integral 
number of records. The acttial length of each segment, in 
words, is given in the segment descriptor words in the 
fixed area of the PRUGRAM file. Unused words at the end of 
the last record of a segment, if any, are ignored, 


The code seqments of a program are often referred to by 
their logical segment numbers. A logical segment number 
simply gives the position of the segment in the segments 
list. The first segment in the segments list is logical 
segment number zero, the next is logical segment number 
one, and so on. Actual segment numbers, which will be used 
in the xCSIr for the program, are assigned by the loader 
when the program is loaded. Segment transfer tables will 
contain the actual segment numbers used when the program 
was last loadea, 


Tnere is a one-ton-one correspondence between the entries in 
the segment descriptor words in the second Subarea of the 
fixed area, and the segments in the segments list. fhe 
first descriptor applies to tne first segment, the second 
to the second, and so on. The record number of any 
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particular segment in the file must be deduced from the 
segment aescriptor woras. It, for example, it were aesireg 
to find the second segment, the first seament descriptor 
word would be used to calculate the number of recoras 
occupied py the first seaqnent. This number woula be auaeg 
to the record numper of the beginning ot tne segments list 
given in the fixed area. tne resulting recora number is 
the first record of the aesired segment. 


Leds The externals list 


The externals list includes entries for all externals 
referenced by tne program. For eacn external it gives the 
segment and STT numpers of tne program segments to ove 
patcned with tne actual segment and STI numpers of the 
external. In addition, a parameter information plock is 
incluaed in each entry, whicn indicates tne calling 
sequence which the program uses to call the external. This 
list is organizeq as a simple linear list. The list is 
terminated by an "entry" with zero in its first word. 


Lilustration 2.5 shows the format of entries on the 
externals list. Each entry begins with a name fiela. The 
P.(034) field of tne name field is unused, and should pe 
set to zero. Following the name field is a word witn tnree 
fields. P.(0:4) of this wora should be set to zero. {t is 


unused, The use of P.(4:4) is not tully known, but it 
appears to be useq py the loader to indicate now the 
external reference was satisfiea. wnen generating tne 


program file, it snould be set to zero. P.(83:8) yives tne 
number of. references to this external by the program. 
(This number shoula never exceed the maximum numper of code 
segments allowed for a single program, since a given 
external should occur only once in any aiven segment 
transfer table.) 


Following the word giving the number of references, there 
is a one-word reference descriptor tor each reference. 
This fiela is thus variable in lengtn. P.(0:8) of each 
descriptor gives the segment transfer table entry number 
for tnis external ina referencing prouram segment, ana 
P.(838) gives the logical segment number of tne reterencing 
program segment. This entire area is shown as a single 
undivided area in illustration 2.5, but tne reader should 
keep in mind that it is a variable length field. 


After tne reference descriptors is a parameter intormation 


block. This parameter information block is in the same 
format used in USL files, 
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Name of External 


i. | Satisfier Number of References 


Reference Descriptors 


Parameter Information 8lockK 





Illustration 2.5 -= Format of Externals List Members 


2e6. The entry points list 


The entry points list gives all entries to the program. At 
least the name of the outer vlock is included in this list. 
All entry points to the program must of course pe in the 
same segment as the primary entry point. fhe logical 
segment number of this segment is indicated in the fixed 
area ain the beginning of the program file. This list is a 
simple linear list. It is terminated by a list “member” 
wlth zero in its first word. 


Members of tne entry points list all consist of a name 
fiela followed by exactly two words. The P.(0:4) field of 
the name field is unused and should be set to zero. The 
tirst of the two words following tne name gives the Pa 
relative address of the entry point. Tne second gives the 
seyment transfer table numver of tne entry point. 


Tne format of entry points list members is shown in 
illustration 2.6. 
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Name of Entry Point 


Ph Relative Address of Entry Point 
ST Numper of Entry Point 
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Tllustration 2.6 -=- Format oft Entry Points List Members 


3. uUSL tiles 


USL files are the principal form of input to the MPE 
seymenter. From a USii file with the appropriate contents 
the segmenter can generate Sb, kL, and PROGRAM tiles. 
"“Relocatable binary modules" are stored in USL’s. 
segmentation, global ana secondary Ds address assignments, 
external procedure reterences, PR relative references, and 
the ‘like have not yet been resolved in these files. 
Although USL files constitute the most complex form of 
compiler output on HP3000 computer systems, they are also 
the most tlexible, giving the user tne most options. 


USL files have the following file characteristics: 
Oo Their record length is 128 woras, 
o They are identifiea by a file code of 1024, 


o Tne file length must be from 4 to 32727 records, 
inclusive. 


o Records must be fixea-length binary, without carriage 
control. 


These restrictions are imposed by tne MPE segmenter. 


Unlike program files, USL tiles may be composed of any 
number of extents. 


3.1. Contents of USL files 


A USL tile is logically divided into three major parts, 
each of which must begin on a record boundary. The parts 
are as follows: 


1. “recoruw zero" containing pointers to the rest of 
the file, list neads, and other miscellaneous 
intormation 


2. the "directory" containing one entry for every kbs, 
segment, ana entry point in the file 


3. the “intormation block" containing all information 
headers and code modules. 


Tnese three partsS always occur in the order specified, and 
are of aftixed length in any given file. Tnis length may 
vary from file to file, but within any’ one file, the 
boundaries are clearly dadetined by information in record 
zero. Record zero is always simply the first record in the 
USL file. 


The directory always pegins with the second record of the 
USL tile, at tile address 00001 OU0 (see 3.2 for a 
discussion of file adaressing). The information block 
always begins at a file ‘address specified in record zero. 
In both the directory and the information block, 
information is placed in successive contiguous locations. 


Record boundaries are not recognized. If any entries or 
neaders are deletea from either ot these two areas, the 
space they formerly occupied is not recovered. {t is 


referred to as "yarbage," and is never used again. 
wever=used directory space is referred to as “availabie" 
directory, and never-used information blocK Space as 
"available" information. 


An intrinsic named ADJUSTUSLF, documented in the MPE 
segmenter reference manual, may be used to expand the 
directory or the intormation block as_ desired. Tne 
directory, hnowever, may not exceed 32K words, and the file 
may not exceed a total of 32K-1 records. 


A USL file may be initialized to the empty state via the 
intrinsic INITUSL. Tnis intrinsic is documented in the MPE 
segqmenter reterence manual. 


in total, then, a USL file consists of the following five 
parts, in this order: record zero, ineuse directory, 
available directory, ineuse information, and available 
information. These areas are delimited by pointers and 


length values kept in record zero. 
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3.2. tile addressing 


SS @Ge@Qeewnneeweepmeweouowe FT 2] 2 @ we wD @ 


It 1S appropriate at this point to discuss USL file 
addressing. Locations witnin a USL file are 1dentitied by 
specifying the word within the file wnhicn is ot interest. 
The tirst word in tne tile is word number zero. Seven pits 
are required to specity tne ottset of a word from the 
beginning of a record. Up to 15 bits may be required to 
specify record within tile. Fuil file aadresses are thus 
normally storea in double words, in whicn strictly speaking 
only tne low order 22 pits are significant. 


File addressing within the oirectory is somewnat agifterent. 
Single word addresses are used. P.(¥:7) is still a worg 
offset into a particular record, but P.(128) 158 now the 
record number. 


Unusea higne-order bits ir both double and single word file 
addresses snould be set to zero, Inis will provide 
compatipility witn tne MPE segmenter. 


The nigh order bit ot a tile address often nas svecia}l 
sigqniticance. It may be used to indicate tnat the aadress 
is a thread link instead of a normal link. It may oe used 
to indicate the ena of a list. It has various uses, whicn 
snoulaq pe carefully considered when interpreting any file 
adaress. 


Tne address zero nas special siaqnificance, It is tne null 
adqdress. No pointer ever points to record zero, 


File addresses are often relative to some location in the 
file. The starting adaress of tne information block is 
normally used as the base address. The value ot a relative 
address (even if it is zero) is added to tne base adaress 
to obtain an actual tile address. Tne nigh-order pit of an 
address should not be involved in this caiculation, since 
it nas special interpretations. It should be set to zero 
in poth the base and the offset before adaina. It is 
essential always to consider whether an address is absolute 
Or relative. This aepends on the context in which the 
address occurs. 


In symbolic form, file addresses are represented by two 
octal numbers. The first is five digits in length, ana 
specifies the record number. The secona is three digits in 
length, and specifies the offset to the desired word in the 


record. These two numbers are separated by a blank. If 
tne higheorder pit of an address is on, then ‘(1)’ is 
prepended to the fiveedigit record number. (lf in the 


given context tne higheorder bit has no signiticance, tne 
°(1)° may be omitted, ) 
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3.3- Record zero 


Record zero occupies the first record of a USL file. It 
contains pointers and counters’ essential to interpreting 
the remainder of the file. Table 3.3 lists tne contents Of 
record zero in oraer. A name is given to eacn field which 
is used as a convenience in referring to the field. 


Table 3.3 *~ USL File Record Zero Contents 


word(s) Name Contents 

U the constant °1° -=| apparently 
identities the file as a valid USL 
file 

1 NDE Number of entries in the directory 

2 DL the directory length, in words 


(number of words which have 
already veen allocated; includes 


garbage) 

3 DG number of words of DL which are 
garbage’ 

4 NDGE numper of directory garbage 
entries 

5 BDL list nead for the block data list 

6 IPL list nead for the interrupt 
procedure list 

7 SL list head for the segments list 

8,9 FL length of the entire USL file, in 
words 

10 SAAD start address of available 


directory space (should be equal 
to 00001 000 + DL) 


11 ADL available directory length, in 
words 
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jable 3.3 *- USL File Fecord Zero Contents (cont. ) 


wOoralts ) Name Contents 


12,13 SAIB Start adaress ot the intormation 
block (should be equal to SAAD + 
AbI.) 


14,15 IBL length of the intormation block, 
in woras (number of words which 
have alreaay peen allocated; 
includes garbage) 


16,17 SAAIB Starting address of the availaple 
information block space 

18,19 AILBL length in words of the available 
information block 

20,21 1BG number ot words of IBL which are 
“garbage’ 

22 NIBGE Number of Garbage information 


olock entries 


23732 apparently reserved; should always 
be set to zero 


33°127 hasn list neads 


The use of many of these fields will be explained in 
Subsequent sections of this paper. The use Of others is 
indicated in illustration 3.3. This illustration labels 
Varlous locations and areas in a USL file with the names 
assigned to the fields ot record zero which refer to those 
portions of the USL file. 
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[Illustration 3.3 == Use of Record Zero Fields 


3-4. The directory 


The USL file directory contains all information needed to 
process and manipulate information contained in the 
information block. A Great variety of items are found in 
the directory, but they are easily classifiea into distinct 
groups. Tne elementary airectory data item is the “entry.’ 
The data structures formed from entries are familiar sorts 
of trees and linked lists. Several implementation aspects 
of the directory, which do not conveniently fall into any 
other section, are listed pelow: 


1. the directory begins at file location 00001 000. 
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2e kach directory entry consists Of some number of 
contiguous words. Entries are not, however, 
necessarily conrtiguous within tne directory. Tnat 
is, there tiay be some unused space between entries. 


3. File recoro pounaaries are not recognized witnin 
tne directory. Entries may span record voundaries 
freely. 


4. All pointers to entries in the directory are 
absolute pointers. If the pointer is containea 
within record zero, or witnin the airectory itself, 
it is a single word, ang not a <douole word, 
pointer. (See section 3.2.) 


Se All pointers to tne information olock shicn are 
contained in tne directory are douole word 
pointers. All sucn pointers are relative to SAIb. 
(See sections 3.2 and 3.3.) 


The entries contained in the directory are related on 
lists. There are only eight types of entries, and only tour 
types of lists, all of which are descrined in aetail in the 
following subsections. 


3.4.1. Directory lists 


The four types of lists in the airectory are as follows: 
tne interrupt proceuure list, the segment list, the block 
data list, and the hasn lists. FEFacn of these tour is 
Giscussed in a separate subsection pelow. With eacn 
subsection is proviaed an illustration of the list 
discussed. 


For every list in the directory, tnere is a certain type of 
entry, or there are certain types of entries, whicn are 
included on that list. with tne exception of the hash 
jists, only entry types appropriate to tne list may be 
placed on tne list. All entry types are appropriate to tne 
nash lists. Entries may be included only on lists for 
whicn they are appropriate. 


Every entry is on exactly two directory lists. It is on 
one, ana only one, of the block data list, the interrupt 
procedure list, and the segment list. It is also on one, 
and only one, of the hash lists. 
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3e4-1-1. Ine interrupt procedures list 


fne interrupt procedure list (°IPL’) is a linear Linked 


list. Its list neac is IPL in record zero (see 3.3). All 
interrupt procedure directory entries are on tnis list. 
Entries are linkea together voy their pvnrother pointers, with 
a link of zero terminating the list. As of tnis writing, 
no further information is available about tne [PL directory 
list. 
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Illustration 3.4.1.1 == interrupt Procedures List 
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Ce er Tne block data list 


[ne olock data list (’HKDL’) is a linear linked list. Its 
list nead is &DL in record zero (see 3.2). Block Gata 
subprograms generate block data RKM’s. All bLOocK data 
directory entries are on the BOL directory list. Tney are 
linked togetner by their brother pointers, with a Link of 
zero terminating the list. 


Record 
Zero 


BlkK. Data 
Entry 
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[IhLlustration 3.4.1.2 -= Block Data List 
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3.4.1.3. Tne segment list 


The segment list is really a tree. The pointer to the root 
of the tree is SL in record zero (see 3.2). Ine following 
three types of entries are found in the tree: segment 
entries, «bM entries (which may be eitner primary outer 
block or primary procedure type entries), and secondary 
entry point entries (whicn may be secondary outer block, 
secondary proceaure with parameters, or secondary proceaure 
witnout parameters type entries). 


The segment entries do actually form a Linear linked list, 
with SL in record zero as the list head. They are linked 
by their brother pointers, witn a link equal to zero 
terminating tne list. 


A segment entry may nave zero or more sons. The immediate 
sons of a seaqment entry must pve RBM entries. The son 
pointer of a segment entry points to the segment entry’s 
tirst son. All the sons Ot a given segment are linked in a 
linear list by their brother pointers. Irhis family list is 
terminated by a link with its nigh-order bit turned on, and 
which points back to tne parent segment entry. For 
example, if a segment entry is located at 00033 O27, then 
the link terminating the tamily list would be (1)00033 U27. 
If this segment entry had no sons, then the segment entry’s 
son pointer would be (1)00033 027. 


Each RBM entry may also have zero or more sons. The sons 
of an RBM entry are secondary entry point entries. The son 
pointer Of an RBM entry is analogous to tne son pointer ot 
a segment entry. It points to the first son, and other 
sons are linked into the tamily by their porothner pointers. 
AGain, the tamily list is terminated by a link with its 
nigh*order bit turned on, and whicn points back to the 
parent RBM entry. If an RBM entry has no sons, then its 
son pointer points to itself, just as in the case of 
segment entries with no sons. 


Ine links terminating family lists in the segment list are 
referrea to as ‘thread’ links, since they refer pack to tne 
root of the subtree in which a node is located. The son 
relationship is definea only from segment to RBM entries, 
and from RBM to secondary entry point entries. The brother 
relationship is detined from seqment to segment, from KBM 
to RBM, and from secondary entry point to secondary entry 
point entries. The father relationsnip is defined from RBM 
to segment, and from secondary entry point to RBM entries. 
Tne tree is thus a lefteson/rightesibling, threaded tree 
data structure. 
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Tilustration 3.4.1.3 == Segment List 
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3-4-1-4- The hash lists 


To facilitate quick access to directory entries by name, 
every directory entry is also placed ona nash list. USL 
files use 95 hash lists, the list heads of which are in 
recoraq zero (see 3.2). Eacn list head is a single word 
absolute pointer into the directory. Directory entries 
which hasn to the same list are linked to each other by 
their hash links (see 3.4.2). Each of the 95 hash lists is 
thus a linear linked list. A zero link terminates a nash 
list. Hashing a name produces an inteyer between 0 and 94, 
inclusive, which is used as an index into the 95 nasn list 
heads to access the hash list on which the entry referred 
to by tne name is located. 


An entry should always be added to a hash list nearest to 
the hash list head. That is, the hash list head should be 
made to point to the entry, and the entry’s hasn link to 
point to tne entry formerly pointed to by the nash list 
nead,. 


The MPE segmenter refers to the °index’ of an RBM, Or 
directory entry. This is a reference to how recently the 
entry was added to its hash list. The mosterecently added 
is indexed one, the nextemosterecently is indexed two, and 
so one "Leaste-recent" on any given list refers to the entry 
on the List witn a hash link equal to zero. When the MPE 
segmenter refers to the index of an entry, only the entries 
of a given name are considered. The entire list is not 
relevant. Tne index zero nas a special meaning. It refers 
to the mosterecent active entry having the given name on 
the hash list (active/inactive entries are discussed in 
the MPE segmenter reference manual). 
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Tllustration 3.4.1.4 == Hasn Lists 
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3.4.2. Directory entries 


In this section, all eight entry types found in the 
agirectory are presented. All entries have some fields in 
common, which together form a standard directory entry 
prefix. Included in tnis prefix is a name field, giving 
the name associated with the entry. ‘’P1’ is used to denote 
an integer pointer whnicn points to the word immediately 
following tne last word used by tne name field. 
{llustration 3.4.2 snows the layout of the prefix. fhe 
contents of the prefix are described in table 3.4.24. 


Table 3.4.2A e- Directory Entry Prefix Contents 


Field Contents 


P(0).€1210) $mumber of words in this entry 


P(O).(€11:5) type of this entry; types have 
following designations: 

segment entry 

primary outer block entry 

secondary outer block entry 

primary procedure entry 

secondary procedure entry, without 

parameters 

interrupt procedure entries 

block agata entry 

secondary procedure entry, with 

parameters 

Other entry types are undefined 


UN hm Ww NO ee 


c= oO 


P(1) the entry’s hash link (see 3.4.1.4) 
P(2) tne entry’s name field 
P1(0) the entry’s brother link 
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i 4 | | 


{ | | 
Number of words in Entry Entry Type 


flash Link 


Name of Entry 





Lllustration 3.4.2 -=- Standard Pretix 


The P(2).(034) field (that is, tne first niovddle of the name 
field) has important uses. The interpretation of this 
tiela aepends on entry type. Ihese interpretations are 
given in taple 3.4.2R. 


Taple 3.4.2B -- Interpretation of P(2).(034) 


Entry Field Interpretation 


1 031 shows whether entry is active or not 
(’i’°’=inactive) 


133 reserved; should be set to zero 
2 031 shows whether entry is active or not 
(°1’°=inactive) 


se shows whether entry is callable 
(°1°=uncallable) 


2:1 shows whether orogram unit must 
execute in privileged mode 


331 reserved; snoula be set to zero 
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Table 3.4.28 = Interpretation of P(2).(03:4) (cont.) 


Entry Field Interpretation 


3 O21 shows whether entry is active or not 
(’1’=inactive) 


isi shows whether entry is callable 
(’°1’°=uncallable) 


232 reserved; snould be set to zero 
4 031 shows whether entry is active or not 
(°1’°=inactive) 


131 shows whetner entry is callable 
(°1’=uncallable) 


231 shows whetner program unit must 
execute in privilegea mode 


321 shows whether entry is nidden 
5 U3l shows whether entry is active or not 
(°1’sinactive) 


131 shows whetner entry is callable 
(°1°=uncallable) 


231 reserved; should be set to zero 
331 shows whether entry is hidden 
6 031 shows whether entry is active or not 
(°1°sinactive) 


132 apparently an interrupt procedure 
type number 


331 reserved; should be set to zero 
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Taole 3.4.2B - Interpretation of P(2).(0:4) (cont.) 


Entry Field Interpretation 


/ Usl snows wnether entry is active or not 
(°1’=inactive) 


P34 set 1f fatal error in block data RBM 


221 set if non-fatal error in block data 
KBM 
33:4 reserved; should be set to zero 
| 03:1 snows whether entry is active or not 


(°1’°=inactive) 


131 shows whether entry is callable 
(°1’°=suncallaple) 


2:1 reserved; should be set to zero 


331 shows whether entry is hidden 


In the subsections of this section all entry types are 
explained. A diagram of most types is presented to 
illustrate the format of the entry. Mention will often pe 
made of “parameter information blocks," "neader 
information blocks," and “header information sets" (’bIb’, 
"HIB’, ana “°HIS’, respectively). HIB and HIS are described 
in 3.4.3, and so are not furtner discussed nere. A PIB 
provides tne calling sequence of a program unit. It will 
always in illustrations be drawn as a single large area, 
but tne reader should keep in mind that it is really 
comprised of one or more words, ana is thus a variable 
length tield. "P2° is used to adenote an integer pointer 
pointing to the word immediately following the Plb. 


3.4.21. Segment entries 


For segment type airectory entries, only a single word is 
appended to the standard prefix. Tnat word contains the 


son link of the entry. (The significance of a son link is 
discussed in 3.4.1.) 
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Standaru Directory Entry Prefix 





{llustration 3.4.2.1 == Segment Entry 


3-422-2. Primary outer block entries 


A numper ot fields follow the standard prefix in primary 
outer block type directory entries. They are described in 
table 3.4.2.2. In this table, ‘°’P’ is assumed to be an 
integer pointer to the word of tne entry immediately 
following the standard prefix. Each fleld is given a name 
to simplify reference to tne field in this paper. 


Taple 3.4.2.2 77 Primary Guter Block Fields 


Fiela Name Contents 
P(0) SONL son link of the entry 
P(1) PUSA program unit starting address 


(adaress within the code 
module of the entry point) 


P(2),P(3) SAC Starting information block 
file address of the code 
module (this address is 
relative to SAIB; see section 
3.3) 

P(9).€02:1) ERROR set if program unit contains a 


fatal error 


P(4).€131) WARN set if program unit contains a 
non-fatal error 
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Paple 3.4.2.7 -- Primary Uuter Klock Fields (cont.) 


rlield Name Contents 


P(4).02214) CUOUFLEN numoer ot «sords in tne Oopject 
code moaule 


P(5) STACKEST an estimate of tne number of 
wOrds Of stacK needea pny the 
proaram unit 


Plo) PDK tne numreer of wor-is of primary 
OB allocated by this proaram 
unit 

P(7) SDb the Number of wOrds of 


secondary DS allocatea py this 
Program unit 


P(3) TRCLEN mumber of words in atabnle 
used py TRACK/300N 


PCY) DATALEN NumMper of words in secondary 
Ob reserved oy DATA (FURI'RAN) 
Or UWN (SPL) declarations 


p(10) to heaaer information block tor 
end of entry tne prouram unit 


wr erewwraeevrwwnwaewrerwrwrewawrorewwwrwonwrworwewwrwvwrawewewwwewaeweweoen © a & a 


SDB ana DATALEN are not tne same thing. DATALEN refers to 
the number of words in &@ ‘secondary Db array. AsSOCciatey 
with each program unit is an area of secondary Ub Space. 
This area includes such things as tne FURTKAN loyical units 
table, format strings (tnose referenced in a reaa statement 
and containing °H’ specifications must be ylobally located, 
to retain tneir values), own/data variables, and the like. 
Inclugeao in OATALEN is only that amount ot storage tu ne 
allocated for own/data variables--this portion of the 
secondary Dt storage allocated by a program unit is 
referred to as the seconoary DB array. [Ine following are 
not Included in DATALEN or SDs: the FORTRAN logical units 
table, TRACE/3000 tables, and conmon arrays. SUB does 
include the number of worus used by globally located tormat 
strings. 
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Program Unit Starting Address 


Start Address of Code Module 


(Relative to SAIb) 


Be Number words in Code Module 


Stack Estimate 





Number words Primary Db 
Naumper words Secondary DA& 


TKACE/3U00U Taodle Length 
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Numper words of Own/Data 


+ Error *% warning 


[llustration 3.4.2.2A ~ 0.6. and Proc. entries sody 


[Ihe first ten words ot this entry are shown in illustration 
3.4.2.2A. Tne format of primary block entries as a whole 
is snown in illustration 3.4.2.2b. 


Standard Directory Entry Pretix 


Outer Block Entry Body 
(see Llllustration 3.4.2.2A) 


Header Information Block 





Illustration 3.4.2.26 e- Primary Uuter Block Entry 
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3e4-2.3. Secondary outer plock entries 


Gnly a single word is appended to the Standard pretix for 
secondary outer block type directory entries. fhis word 
Indicates the location of the entry point in tne code 
module associated witn the parent directory entry. Ihe 
wOrd 1S given as & word-ottset trom the beginning of the 
code module, ana so is analogous to PUSA, described in 
3.4.2.2. 





Standard virectory Entry Prefix 


Projram Unit Starting Address 


Illustration 3.4.2.3 -= secondary Yuter Block Entry 
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3.4.2.4. Primary procedure entries 


Primary procedure type directory entries appena to the 
standard prefix exactly the same information as 1S appended 
by primary outer block entries, with one exception. 
Between DATALEN and the neaaer intormation plocK, a 
parameter intormation plock is inserted. 


3.4.2¢5- Secondary proceaure without parameters entries 


The secondary procedure without parameters directory entry 
type appends to the standard prefix only a single word. 
Tnis word contains the aadress of tne entry point to the 
code module associated with tne parent entry. Ine address 
is a word-offset trom the veginning of tne code module, and 
so is analogous to PUSA, described in 3.4.2.2. 


Standary Jirectory Entry evrefix 


Prinary Procedure Entry body 
(see Illustration 3.4.2.2A) 


Parameter Information BlocK 


Header Intormation Block 





Llllustration 3.4.2.4 -- Primary Procedure entry 





Illustration 3.4.2.5 -=- Sec. Procedure, ho Parms., Entry 


3264-2.-0. Interrupt procedure entries 


After the Standard prefix, interrupt procedure type 
directory entries append tive words. Tnese five words are 
followed by a header information block. Ine proper 
interpretation of the five woraS hnaS not yet »vneen 
determined. 


364-22]. tHlock data entries 


A olock data type directory entry appends after tne 
standard prefix a numoer of subentries. Each subentry 
contains information for one block of common. (AS far as 
the segmenter is concerned, every plock of common is named. 
Tne name "CUM’" is used to reter to ovlank common.) fhere is 
no explicit indication of the number of subentries present. 
This must pe deaucea from tne subentries themselves, and 
from the number of words in the entry as a wnole. 


Tne first vord of a subentry gives tne numoer of words in 
the common block. Following this is a name field giving 
the name of tne common olock. beginning in the word 
immediately following the name tield, tnere is a neader 
information block for the subentry. Thus, ina manner ot 
speaking, the common block name and length are prepended to 
tne relevant header intormation block. 


NUMber of woras in Common BLOCK 


Name of Common block 


Heager Information Block 
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lllustration 3.2.4.7A -= Block Data Subentry Format 


Standard Directory Entry Prefix 


Glock Data Suoentry 


Block Data Subentry 





Lllustration 3.2.4./B *= Block Data Entry Format 
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Standard Directory Entry Pretix 


Program Unit Startina Address 


Parameter Information Slock 





Lllustration 3.4.2.8 == Sec. Procedure, with Parms. Entry 


364.2.8. Secondary procedure with parameters entries 


One word, and then a parameter intormation block, are 
appended to the standara prefix in secondary proceaure with 
parameters type directory entries. The word placed between 
the prefix and tne PIB contains tne address of the entry 
point to the code module associated witn the parent entry. 
This address is given as a wordeoftset from the peginning 
of tne code module. 


3.4.3. Header information blocks 


In a USL tile in Pk, a ‘*header’ is an entry in the 
intormation block of tne file which provides information 
necesSary for relocating a program unit, and for binding it 
with other program units. The various types of headers 
whicn are possible are discussed in section 3.5. In this 
section, the header information blocks tound in directory 
entries are aiscussed. HIB’s are used to provide 
infOrmation about the number, tyres, and lenaths of headers 
associated with a directory entry. 


A neader information block is divided into header 
Information sets. Eacn HIB is amore or less distinct 
entity. Any Number of header information sets (including 
zero) may ove includeaq in any header information block, 
Tnere is no explicit inaication of the numper of header 
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information sets are in a@ header information block. fThnis 
must be deduced from the HIB itself, and from the number of 
words in the airectory entry as a whole. A HIS begins witn 
a word which specifies in its (12:15) fiela the number of 
‘neader descriptor woras’ that are present in the HIS. The 
(0:1) tield of this word is set to zero unless tnis HIS is 
the last HIS of the HIK. In this case, (9:1) is set to 
one. This word is tollowed by a double word flle address 
which is relative to SAIB (see 3.3). This address points 
to the tirst word of the oft the first of the actual headers 
corresponding to the KIS. (All headers corresponding to a 
given HIS must be contiguous in the intormation block. see 
section 3.5.) 


In the tnird and tollowing words of a HIS are header 
descriptor words. There is one descriptor word for each 
neaaer associated with the HIS, and tne descriptors are in 
the same order as the neaders themselves in the information 
b1lOCK. A neader descriptor nas only tnree fields. The 
first, (0:1), is unused, and should be set to zero. tne 
second, (1:10), gives the lengtn of the associated header 
in words. (The lengtn of neaders is tnus limited to a 
maximum of 1023 #£4.words.) Tne third, (11:5), gives the 
number of the type of the header. Header type numbers are 
presented in section 3.5. 


3.5- The information area 


The intormation block inauwUSL file contains all header 
entries. All addresses in the directory which refer to the 
information block are relative to SAIB (See 3.3). Because 
of this, the entire information block may be moved up and 
down in the file, changing only a few fields of recora 
zero. Record boundaries are not recognized in the 
intormation block, but it should nonetheless begin ona 
record boundary. 


3-5-1. Code modules 


A code module is a special sort of header. lit has no 
associated header descriptor word, it may be longer than 
the normal maximum of 1023 words, and it is never 
explicitly included in any HIS (see 3.4.3). It may, 
nowever, oe placed anywhere within tne headers associated 
with auHIS. Tne starting address ot the code module, SAC 
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(see 3.4.2) must be used to detect the presence of the code 


while sequentially processing tne headers. If tne code 
module is not needed when detected, it may simply be 
skipped. It is, as are all hneaders of a single HIS, 


contiguous with both the preceding (if any) ana toilowing 
(if any) headers. 


The code module contains for tne most part finished code, 
ready to be placed into a program. Tnere can be many 
exceptions to this, however, depenaging on otner neaders 
associated with directory entries associatea witn tne code 
module. There are various linear lists and relocatable 
addresses in the code module itself which are used by these 
other headers, The relevant lists and addresses will ve 
discussed pelow together witn the appropriate neaders. 


Se08 2% Information headers 


There are twelve types of information headers. They are 
numbered as follows: 
null (a garbage header) 
PCAL, LLBL, or program unit PB address 
PB address 
Own/data variable (for address correction) 
secondary DB initializations 
a taple for TRACE/3000 
variables declared GLUBAL 
Varlables declareo tXTERNAL 
primary DB declarations and initializations 
common (Caccomplishes only address correction) 

10 FURTRAN logical units 

11 globally located formats 
These numbers are used in header descriptor words. (Header 
descriptor words were introauced in section 3.4.3.) every 
header begins with a header descriptor word which describes 
it. The format of these descriptors is as follows: 

(O31) reserved, should be set to zero 

(1:10) the length otf the neader in words 

(11:5) the number ot tne neader type 
Although all headers begin with a descriptor word, eacn is 
thereafter highly individual. Each type is describea in a 
separate subsection below, 


OeCnNO UWS WDE © 


All of tne headers associated with a given HIS must be 
contiguous within the intormation block. The directory 
gives only the file address of the first word ot the tirst 
header of any HIS. If the neaders are not contiguous, it 
will not be possible to locate tnem in the file. 
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3.5.2.0. Null neaders 


A null neader is a garbage entry. It simply takes up as much 
space as indicated in the header descriptor word. lit has no 
Signiticance to the program unit with which it is associated. 


3.5.2.1. PCAL headers 


PCAL headers provide all information needed to link the 
program unit to external program units. It actually has 
tnree functions, as follows: to make PCAL patches, to make 
LLBL patches, and to make procedure PB relative address 
patches. It is structured as indicated in table 3.5.2.1. 


Table 3.5.2.1 “= PCAL Headers 


Field Contents 
P(Q) header aescriptor word 
P(1) word otfset into code module to the 


first word of a linked list of 

references to the program unit 

described in the neader; each word in 

tne list in tne code module has the 

following formats: 

e(O03:i) O=patch in a PCAL instruction, 
i=patch in an LLBL instruction 

(131) Ozpatch as indicated by .(0:1) 
f=patcn in PB relative address 
of the program unit 

~(2314) link to next list item (this 
is a selferelative backwards 
pointer; the list terminates 
with a zero pointer) 


P(2) a name field, giving the name of the 
external program unit (P(2).(034) is 
unuseg, and should be set to zero) 


Pi following the name field is a 
parameter information block 
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3-5e2-e-2- PB address headers 


This header provides a means of patching words in the 
program unit which contain PB relative addresses. After 
the header descriptor word, the neader is simply a series 
of pointers, each of which is a wordeofftset into tne code 
nodule. (fhe number of tnese pointers must be deauced from 
the lengtn of tne neader aS a wnole.) In each word in the 
code module thus pointed to, the compiler must place a Pr 
relative address. This address will be corrected by the 
MPE segmenter at prepare time by adding to it the PB 
relative address of the tirst word of tne program unit. 


32-5e2-3-6 OUwn/s/data headers 


At compile time, the run time address of an own or data 
variable is not known. It is assigned at prepare time. 
the MPE segmenter solves this problem py requiring the 
compiler to place in tne code module a_ pointer to tne 
variable, This pointer will of course then be part of tne 
code at run time. Tne compiler initializes tnis pointer to 
Che offset into tne program unit’s secondary Ds array 
assigned py tne compiler to tne variable. At prepare time, 
the segmenter will add to this value the DB offset of the 
program unit’s secondary D8 array, thereby providing the 
code at run time witn the correct pointer value. 


After the header descriptor word, the entire header 
consists of pointers each of whicn is a word-offset into 
the code module. (Tne number of pointers must be deduced 
from the length of the neader.) kach points to a location 
whicn is to pe patched at prepare time. The high oraer pit 
of the pointer determines whether a byte or a word pointer 
is being initialized. If .(0:1)=1, then tne contents ot 
the code module word specified by the word offset in 
-€1315), and the correction added at prepare time, are byte 
offsets. If .(031)=0, they are word offsets. (It is 
believed that the high order bit of the code module word 
pointed to is also interpreted in this way. That is, it 
either nigh order bit is on, either in tne header pointer 
Or in the code module word, then the address is to be a 
byte address.) 
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3.5-2.%4. Secondary DB initial values headers 


This meader may be usea to place initial values into the 
program unit’s secondary DB array. Tne word which follows 
the neader descriptor word gives the offset into tne 
seconaary DH array at which the tirst of tne given initial 
values is to be placed. 


Tne third word of the neader nas two fields. Tne .(0:1) 
field determines whether a byte initialization or a word 
initialization is to be performed, It .~.€O0s1)J=1, tnen the 
second word of the neader is a pyte offset, and the fourth 
wora Of the header is a pyte count giving the length of the 
initial values in the header. In this case, the initial 
values beyin in tne fifth word of the header ana continue 
fOr as many bytes as the fourth worda indicates. If 
-(03:1)=0, then the second word of the header iS a word 
ottset. In this case, the initial values begin in the 
fourth word, ana continue to the end of the header. 


The .(€1:215) tield of the tnird word gives a replication 
tactor. The initial values specifiedaq in the header will be 
placed in successive locations in the secondary DB array as 
many times as indicated py this fiela. Thus, if the 
initial values are "xxyxx" and the replication factor is 2, 
tnen "xxyxxxxyxx" will be placed into the secondary Db 
array, beginning at the location specified in tne second 
word of the hneader,. 


3.52-2-5- TRACE/3000 neader 


This header provides aintormation for use at run time by 
TRACE/3000. After the neader descriptor word, tnere is a 
word pointing to a linked list in the code module. After 
tnis, wveginning in the third word of the hneader, and 
continuing to the ena of the header, is data which is 
believed to be initial values of some sort. No further 
information is availapie as of this writing avout this 
header type. 


32.5.-2-6. Global variable headers 


It is possible to declare a variable GILOBAL in one program 
unit, EXTERNAL in another, separately compiled program 
unit, and have the MPE segmenter resolve all reterences to 
tne variable. C(SPL/3000 is the only Hewlett Prackara 
lanquage allowing explicit daeclaration ofr GLUBAL or 
EXTERNAL attributes.) Following tne neader descriptor word 
is a data descriptor word, which gives the type ana 
Structure of tne variable, Tne f1elds of this data 
descriptor are as follows: 
(934) the mode ot tne variable (U=null, 1:2 
value, Z=reference) 
e(4360) =the Varlaple’s structure (0Q=simple 
Variable, i=pointer, 2=array) 
(1036) the type of the variable (0=null, 1: 
logical, z=inteqer, 3=byte, 4=reai, 
S=aouble, o=longq, 7=complex, S&=label 
(passed SPI tashion), Y=chnaracter (as 
in FURTRAN/3000), 10=labe] (passed in 
In FORTRAN/3000 fashion), li=any) 
in tne left byte ot the third word ot the neader is tne run 
time DB relative address of tne variable. (Global storage 
adagress assignments for primary D&B are normaily made by a 
compiler wnile compiling an outer plock, and are not in any 
way relocated by the seymenter.) The .(€(8:4) tield of the 
third word is reserved and should be set to zero. (1234) 
contains the length ot the name ot the variable, in pytes. 
[ne name itselt begins in the lett byte of the fourtn word, 
ana continues for aS many bytes as necessary. tne name is 
always an integral numper of words in length, ana s0 a byte 
is sometimes wasted. 


3.5-22-/. External variable headers 


A Varlaple declared EXTERNAL is to be matched at prepare 
time with a variable declared GLOBAL in some other program 
unit. Tne first word of the neader 1s of course a header 
descriptor word, The second word 1s a data descriptor 
word, wnich has the format aescribed in section 3.5.2.6. 
Following the second wora is a name tielda. The .(0:1) bit 
of the first word of the name tield is a ’trace’ bit. If 
it is on, it indicates that the variable may be traced by 
TRACE/3000 at run time. .(1:3) is reserved, and should be 
set to zero. 


If the trace bit is on, ‘then in the word immediately 
following the name field is an oftset into the TRACE/30UU 
symbol table. If the trace bit is oft, this otfset is not 
present. 
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Following the name field, and the TRACE/3000 symbol table 
oftset, if present, is a series of pointers, each of which 
is an offset into the code module. Each points to the 
tirst ot a list of instructions to be patcned witn the 
adaress of the appropriste GLOBAL variable. tach of the 
instructions to we patcned must be a memory reference 
instruction, since GLUKAL variables will always reside in 
the primary Db area. The address tields of the 
instructions to be patched (the right pyte in memory 
reterence instructions) serves as tne link tield for the 
list. Tne links are selferelative backward pointers. Each 
list is terminated by a zero pointer. 


There is no explicit indication of the numper of pointers 
in the header. This must be deduced from the length of the 
neader,. 


3.5-2-e8- Primary ULB headers 


For the purposes ot the MPE segmenter, primary Db words are 
classitied into word pointers, pyte pointers, and data. 
After the descriptor word in this header tnere is a series 
of words, each of which is divided into eight twoe-bit 
fields. All tnese tields, in order of occurance, 
correspond to primary DB locations. The first it tor Dbt0, 
tne second tor DB+t1, and so on. the values of the fields 
are interpreted as follows: 
0 the initial value is not an address 
1 tne initial value is not an address 
2 the initial value is a word address which 
points to the secondary Db area 
3 the initial value is a byte address which 
points to the secondary DK area 
Initial values in the neader that are addresses are 
relative to the beginning of the program unit’s secondary 
DB area. Tne entry, after the array of twoebit-field 
words, contains initial values. ‘here must be PDB (see 
section 3.4.2.2) two-bit fields, and PDB initial values. 


There may be a slack word between the twoebit-field array 
and the initial values. Because of this, the initial 
values should always pe accessed from the ena of the 
header. Tnat is, if P is an integer pointer to tne last 
word of the header, then P(-(PDBKB°1)) accesses the first 
initial value, 


Normally, only an outer block program unit would make use 
of this heager type. Non-outer block program units should 
not be allocating primary DB storage, and the value of PDs 
for tnem should be zero. 


3.5.2.9. Common variable neaders 


Tne MPE segmenter allocates secondary DB storage for all 
common »plocks. In order tor a program unit to access a 
variable in common, it must use this header. for each 
common varlable referenced in one of these heaaers, the MPE 
segmenter will allocate a pointer in the primary DH area, 
and properly initialize it to point to tne common variable. 
opecified instructions will be patcned with tne address ot 
tnis pointer. 


Following the header descriptor word is an integer which 
gives the length in words of the common block to which the 
header applies. heginning in tne third word is a name 
field, giving the name of the common block to whicn the 
header applies (blank common is named “COM’"). The .(034) 
tielu of the name tiela is reserved and should ve set to 
zero, 


Beginning in the word immediately following the name tield 
is a series ot variable descriptors. Inere is no explicit 
indication of the number of variable descriptors in the 
neader. This must be deduced from the header’s lengtn and 
contents. Table 3.5.2.9 gives the format of variable 
descriptors. 


It must be noted that if the trace bit (P(0).(121)) is not 
on, then the displacement into the TRACE/3000 array (P(2)) 
is not included. It is simply omitted, and the list heaas 
move up to fill in its place. 
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Table 3.5.2.9 == Variable Descriptor Formats 


Fiela Contents 


P(0).(9031) O=DH pointer is to be of type word, 
1=Dek pointer is to be of type byte 


P(O).(131) "trace bit’; O=variahle will not be 
traced py TRACE/3000 at run time, 
l=variable may oe traced 


P(0).(02314) the number of lists of instructions 
which are to be corrected (there are 
this many list neads later in the 
Varible aescriptor) 


P(1) the displacement witnin the common 
block of the variable 


P(2) displacement within a TRACE/3000 
array Ot information about the 
variable (NOTE $3 tnis field is 


present only if tne trace oit 
(P(0).(131)) is set; otherwise it 15 
completely omitted) 


P(3) tne list heads of the lists of 
to instructions to be patched; eacn 
P(2+P.(2:14)) list head is an offset into the code 
-or- module to the first word of a list 
P(2) (the lists are formed the same as 
to the code module lists used by 


P(1+¢P.(23:14)) EXTEPNAL variable neaders, described 
in section 3.5.2.7) 


3.52-2e-10. FORTRAN logical units table headers 


This header indicates which FORTRAN logical units are 
referenced by the program unit. The MPE segmenter will 
construct the FURTRAN logical units table from tne 
information contained in FLUT headers. After the header 
descriptor word there are exactly seven words. These words 
contain a bit map, in which the first bit corresponds to 
logical unit numper zero, the second to logical unit 1, the 
third to LU 2, and so On. If a bit is on, the 
corresponding logical unit will be included in tne FLUT 
table at run time. The bits are numbered from left to 
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riant. The “lettemost’ word is tne one which occurs 
nearest to tne header descriptor word. lLeyal LU’s range 
from 1 to 99, inclusive. 


3.5-2e11. Format neaders 


Formats whicn include an ‘H’ specification, and are 
referenced in @ kKEAD statement, must pe clonalily locateu to 
retain between calls to tne program unit values read into 
the "H® specification. Tnis header allows tnat. lt 
contains a fOrmat stringy wnicn is to ne placed in tne 
secondary WB area, 


After the header descriptor word is a word whicn gives a4 
wOorao offset into the code module, Tne code moaule worg 
thus indicated is the first ot a list of words to pe 
lnitialized at prepare time with the Dis relative address of 
the ftormat string. within tne list in tne code moaule, the 
©(2314) tield of eacn menber Of tne list 18S a 
self-relative, backward pointer to tne next list element. 
A link of zero terminates tne list. If tne .(u:l) tiela o} 
such a code module word is set on, tnen the DB relative 
pointer placed into that word is to be a pyte agaress;: it 
o(U31)=0, then the DR relative pointer placed into the coue 
mouule word is to be a word address. Tne pointer placeg 
into the word will point at run time to the peqinning of 
the format string. 


Tne thira word of the neacer gives the lenyth, in oytes, ot 


the format string. The tourth and following words, as many 
aS necessary, contain the tormat string itself. 
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TITLES HF 3SOO0O/0FTIMIZING ON-LINE FROGRAMS 


AUTHOR? ROBERT M. GREEN 
ROBELLE CONSULTING LITT. 
#130-5421 1LOTH AVENUE 
DELTA, B.C. VAM ST? 
CANATA (604)943-8021 


l have identified five deneral erincireles which helr in 
ortimizing the rerformance of on-line rrograms: 


xX Make each dise access court. 

Kk Maximize the value of each terminal ineut. 
K Minimize the run-time fFrosram size, 

xX Avoid constant demands for executions. 


xX Ortimize for the common events. 


FIRST PRINCIFLE: MAKE EACH DISC ACCESS COUNT 


[lisc accesses are the most critical resource om the HF 3000. 
The sustem is carable of rerforming about 30 dise transfers 
rar seconds and they must be shared by system rrocesses 
(spooling: comsole oreratory etc.)» memory management and 
user Frodrams. (This rate can be increased to 58 rer second 
under the best circumstancesy and can dedrade to 24 rer 
second when randomly accessing a larse file.) Another 
interesting fact is that a 4096-word transfer takes about 
the same overhead as a 128-word transfer. Therefores it is 
hetter to read 4096 words in one transfer than to read 128 
words 32 times. Another roint to remember is that IMAGE 
database transactions reauire a lot of immediate disc 
secesses (from a DBUFDATEs which does one disc writers to a 
multi-key DBFUT that may reauire ten or more disse 
reads/writes). 
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Some of the orerations that consume extra dise accesses or 
the HF 3000 are} 


Increasing the rumber of keys in a detail dataset, thus 
causins IMAGE to access an extra master dataset on 
each DRFUT. Alsoys making a field a key value means 
that a DBDELETE/OBFUT is reawirecd to change it (which 
16 10 times slower than a DBUFIIATE). 


Increasing the erogram stack size by 89000 Hutessy thus 
causing the MPE memory manager to rerform extra 
SWaPPrIingd dise accesses to find room in memory for the 
larser stack. 


Imerorerly sesmenting an active PTOSrsams Causing many 
absence trars to the memory manaeser to bring the code 
sedments into main memory, 


lefininsg 3a database or KSAM file with overly large 
blocksizey thus forcing each user terminal to agccess 
8 large extra data segment that must be SWarPred ift 
and out of main memory, (Note? the trade-offs will 
change when Cif?) IMAGE is revised to use shared 
buffers.) 


NOBUF [lisc Accesses 


When designing your mext on-line arrlications see if there 
is some way that a random dise file can he wsed instead of 
an IMAGE dataset or a KSAM file$ Then Orem that file with 
NOKRUF and access it via directed reads and writes to 
SPecific blocks. Normallys when yoy Oren 32 filey the 
FrOsram 16 assigned an extra data sesment to hold the buffer 
seace for the file. Transfers hetween the file and the 
Frodram are always done through this extra data sessment. 
When the rrodram reauires a records, MFE first checks to see 
if the record is already in the extra data sedment buffers} 
if sor it is merely transferred from the extra data sedment 
to the user stack. If the bloc containing the desired 
record is mot in the buffers, MPE issues a read aseinst the 
disc to bring the block into main MAMOTY « 


Althoush this sounds very clever and efficients it has one 
major flaw? the extra data segment itself can he swarred, 
This means that in order to do ary file access on a busy 
sustemy it may be necessary to read the extra data segment 
imto memory before accessing the date in the dise file. On 
a heavily loaded systems this could cause 8&8 larde number of 
unnecessary disc transfers. NOBUF access does away With all 
this by rroviding a direct interface hetween the user 
Frosram and the dise files. KElocks are transferred to and 
from the user stack and the dise Without anyw intervenins 
buffer area. NOBUF is the fastest way to wse random dise 
storage from 3 user frosgram. 
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The user Frodram must rrovide its own buffer srace im the 
stack and call for transfers of data via the block mumber 
within the file. When multi-record access 16 usedsy it is 
rFosSsihble to transfer multirle blocks at a time. The user 16 
resronsible for determining which block contains the record 
that he desires and where within the block the record is 
located. Simrle subroutines cam be written to handle this 
transformation. 


A tyricsal use for this kind of file is es a data entry 
transaction file. As the orerator enters the datay it is 
buffered im the stack until @ block is fulls them the entire 
block is written to the disc in one oreration. For even 
hetter throushrut and resreonse times you might try writing 
the blocks to the disc with the NO-WAIT ortions when this 1s 
usedy MFE overlars the write oreration to the dise with your 
next erint and read from the terminal. Without NO-WATT» 
your Frosgram would be susrendect until the dige write could 
be comeleted by MFE,. 


(Warnins! Be certain that you know when the end-of-file is 
urdateds otherwisey you might find that you have an emety 
transaction file when the system crashes. I sussest that 
you move the end-of-file to the limit of the file at the 
start of the day by writing a mull entry in the last record 
eosition and then closins the file.) When the transaction 
file is full (or the day ends)» &@ batch frosgram is used to 
rut the transactions into the final IMAGE dataset or KSAM 
file. This Job can be done in low feriority or after hours. 


SECONI PRINCIFLE MAXIMIZE THE VALUE OF EACH TERMINAL REAT 


Fach time a rrosram reads from the terminals it is susrended 
and may be swarred out of memory. When the orerator hits 
the carriage return keys the inreut oreration is terminated, 
and the rrocess must be disratched adain.e In order to 
disretch a rrocesss MFPE must ensure that the data stack and 
at least one code segment are resident in main memory. If 
the rrocess is sdoins to access the disc, it may he necessary 
to make an extra data sedment resident also. Unless the 
comreuter has enoush main memory so that no user segments are 
ever swarred outer it is desirable to have the rrocess set as 
much work done aS rossible before it susrends for the next 
terminal inreut Cand is swarred out asain). 


The simelest way to rrodram data entry aerlications is oy 
rrometing for and accerting only one field of data at a 
time. This is also the least efficient way to do it. The 
user data stack must be made resident every time the user 
hits ‘return’, (Thereforey the less often the user nits 
‘return’, the larger your stack can afford to be.) Since it 
is inefficienty fast resronse time cannot be guaranteed, and 
the resulting delays are very irritating to orerators. They 
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Can mever work we any ineut sreeeds hecause they mever know 
when the comruter is ready for the next ineut line. If 
resronse time and throushreut are the only considerations: it 
is always rreferable to keer the orerator turing as longs as 
rossible before hitting the ’return’ key. Multirle 
transactions should be sllowed rer liney with suitable 
seraratorss and multirle lines should be allowed without a 
‘return’ « 


THIRD FRINCIFLE: MINIMIZE THE RUN-TIME FROGRAM SIZE 


The HF 3000 is an ideal machine for ortimizins because of 
the many hardware features available at rum-time to minimize 
the effective size of the rrograme Even auite large 
aeelication systems (6000 lines of code) can be orssnized to 
consume only 3a small amount of main memory at any one time. 
Each executing rrocess om the HF 3000 consists of a sinsle 
data segment called the "stack"» and one or more extra data 
sedments for system storasdey such as file buffers. Althoush 
8 FrTocess 1S always executing some code in a code sesmerty, 
the code does not errorerly belongs to the rrocesss since one 
cory’ is shared by all rrocesses in the sustem. If a rrogram 
1s to be executed by several terminalss most ortimizins 
should be directed to the data areas (which are durlicated 
for each user). 


Large rrosgrams which sre mot losically segmented make it 
harder for the memory manager to do its Joby amet thus cause 
many disc accesses to be consumed in swarreins. In an 
extreme casey the system can almost be brought to @ comrlete 
standstill by a very larse rrogram executing on many 
terminals at the same time. The articles listed in Arrendix 
A rrovide stratedies and exameles for code sesmentation. To 
SimrPlify a comelex rroblemy follow these suidelines!t 1) rut 
initialization, termination and error handling in serarate 
code segments 2) minimize the ruimber of calls across 
segment boundaries at runtimes 3) remain in a sesment as 
longs as rossibles 4) keer segments small (2K-8SK words)» but. 
don’t use too many sedments (MFE has @ limited overall code 
segment caracity). 


Many more terminals can be surerorted om a siven sustem if 
data stack sizes are kert modest (ext less than 6000 bytes 
om a 192K-byte machine), and if the code is rrorerly 
segmented. The simelest way to keer the stack small is to 
make g11 data variables local (DYNAMIC im COBOL) anc to use 
Slobal storase only for buffers and control values that must 
he accessed by 311 subroutines. The reason that this is so 
effective is that dynamic local storage is sllocated om the 
tor of the stack when the subroutine is entered and is 
released automatically when the subroutine is left. This 
means that if the main rrogram calls 3 larse subroutines in 
successionys they ell reuse the same srace in the stack. The 
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stack meed only be larse enough for the deerest nesting 
Siltuatiorie 


Since the amount of dynamic stack srace that will be 
reauired by the frrodram is not known at the start of 
executions the 3000 rrovides methods (Choth sutomatic and 
erosgrammatic) to exrand the dynamic area. Whenever a stack. 
overflow occursy MFE automatically allocates more srace Cur 
to a MAXIIATA Limit). Unfortunatelys there is mo automatic 
mechanism for reducing the stack size when that additional 
sre3ace is no lonser needed. The user arrlicsation Frogram can 
include a check in the mainline and shrink the stack beck. 
down to the desired size after returning from arn oversize 
SUbDrOUTLITNEG (See Arrendix BK for am examele,.) 


The other maJor way to reduce the size of @ data stack is to 
ensure that constant data items (such as error messastesys 
screen Gisrlays) ere stored in the code segment instead of 
the data sedment. Since they are never to be modifiedys 
there is mo losical reason that they must be im the data 
stack. Ey moving them to the code segments one cory of them 
cam be shared by all users running the errogram.e In SFL» 
this is done by including =FR in a local array declaration 
or MOVE’ins a@ literal strings into a buffer. In COBOL» 
constants can be moved to the code sedment by DISFLAY’ins 
literal strings in rlace of declared data items. Im 
FORTRAN: both FORMAT statements and DISFLAY’ed literals are 
stored im the code, 


FOURTH PRINCIFLE: AVOII CONSTANT DEMANDS FOR EXECUTION 


The HF 3000 is a multirrosgramming,y virtual memory machine 
that derends for its effectivenss on a suitable mix of 
erocesses to execute. Although the sizes of the sedments to 
he swarred have an effect on rerformance, this is derendent 
uron the frequency with which memory residency is demanded. 
Given the same overall configuration and arrlication Frogram 
Sizesy the system Surrorts many more terminals if each one 
only executes for 5 seconds every 30 seconds than if each 
one must execute for 60 seconds at a time. Each additional 
terminal that is demanding continuous execution Cin high 
epiority) makes it harder for the orerating sustem to 
erovide rrorer resronse time to 311 other terminals. 


Here gre some examples of the kind of oreration that can 
destroy resronse time if rerformed in high eriorityes 


ELDIT/3000» 2 GATHER ALL of a@ 3000-line source file. 
QUERY» serial read of 1007000 records 


SORT, sorting 5O»000 records. 
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COBOL: comeriling om 4 terminals at once. 


All of these orerations should be done in low rriority in 
batch STREAM Jobs. These Jobs can even be created 
dynamically hy on-line ferograms. In this ways the on-line 
user Still reauests the hisgh-overhead orerations but the 
system fulfills the reauest when it has the time. 


FIFTH PRINCIPLES OFTIMIZE FOR THE COMMON EVENTS 


In any a@relication where there is a larse variation betweer 
the minimum and maximum load that @ transaction can causes 
the frogram should be ortimized around the most common size 
of transaction. In anv @ee lication with a large rmumber of 
on-line funetionss it is likely that a small mumber of 
funetions are used most of the time. In this casey all 

Or timization efforts should be aimed at the commonly used 
funetions and other functions left as is. This is 
esrecisally feasible om the HF 3000 because of code 
segmentation and dynamic stacks. 


If N is the average mumber of records in a transaction Ci.ey 
the number of lines om & customer orders maximum is SOO)» 
then allow room in your stack for N records. If vou only 
Bllowed for one records then there would be unmeeded disc 
thrashing. Alternatively, if you rrovide room for the 
maximum mumbers then the data stack is much larser than 
actually meeded most of the time. Havins @ larser cate 
Stack may cause the system to overloads eliminating the 
benefits of keering the records in your stack. It is 
recommended that room in the stack be allowed for slightly 
more than the average numbers and that a NOBUF disc file be 
used to “rase" this area on very larse transactions. 
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OPTIMIZING CASE STUDY #1: QEDIT 


QEDIT is a hish-sreed, low-overhead source frosgram editor 
develored hy Robelle Consulting Ltd. The rrimary obJective 
of QEDIT is to provide the fastest rossible editing with the 
minimum Fossible system load. Other obJectives include 
conservation of dise sracey similarity to EXIT/3000 in 
command syntax, ability to recover the workfile following a 
sustem crash or rrogram aborts and increased rrosrammer 
rroductivity. 


REDDIT and the First FPrincirle: Dise Accesses 


In order to reduce disc accessess QELIT had to eliminate the 
overheads of the TEXT, KEEF and GATHER ALL commands of 
ENIT/3000. These three orerstions have the most drastic 
imract uron the resronse time of the other users. QEDIT 
attacks the rroblem of KEEFPs by eroviding an interface 
library that fools the HF comrilers into thinking that ~@ 
QENIT workfile is really 3@ "card imase® file. AS a results 
it is never necessary to KEEF @ workfile before comrilaine 
ite Since KEEFs sre rarely used» most TEXTs are eliminated. 
TEXT is only needed when you want to make a backur or 
duslicate cory of an existing file. It was anticirated that 
most users would maintain their source files exclusively in 
workfile formats so the TEXT’ins of workfiles was ortimized 
(by using) NOBUF»y multi-~record techniques) to be at least 4 
times faster than 3 normal TEXT of a card imase file. The 
GATHER ALL oreration is slow because it makes a cory of the 
entire workfile in another file. QEDIT renumbers ur to 12 
times faster be doings without the file cory. 


Lise accesses during imberactive editing (addr deletey 
change» etc.) were minimized by racking as many contiguous 
lines as rossible into each disc block. The resultins 
workfile is seldom over SOX of the size of a normal KEEP 
file or 25% of the size of an EXIT/3000 K-file (workfiled. 
Most QELIT users maintesin all of their source rfrrosgrams in 
workfile forms since this saves disc sracey simelifies 
orerations (there need only be one cory of each version of 2 
source rFrodram)»s and rrovides ortinum on-line rerformance . 


QEDIT always accesses its workfile im NOBUF mode and buffers 
all new lines in the stack until @ block is full before 
writing to the disc. Wherever rossible in the coding of 
QELITs unnecessary disc transfers have heen eliminated. For 
examreles the workfile maintains only forward direction 
linkade rointersy which reduces the amount of dise I/0 
substantially. Results of a lossingd test show that reducing 
the size of the workfile and eliminating the need for 
TEXT/KEEP reduces disc accesses and CFU time by 70-904. 


C-93.7 


OR TINIZE 


QENIT and the Second Frincirele! Terminal Accesses 


QENIT allows multirle commands rer liners elus multirele data 
lines rer data line ineut Ci.er you cam enter 7 lines of 
text without hitting ‘’returnm’). ALL interaction with the 
terminal is done directly throushn the REANX and FRINT 
Lmstrinsics. 


QENIT and the Third FPrincirele! Frogram Size 


QELIT is @ comeletely new erosgramy written in nishls 
Structured and rrocedurized SFL. The resulting rrogram file 
consists of 7 code segments of 1780 words (decimal) each. 
Only two code segments are reauired for most editine 
commands» while the most common function Cadding mew Lines) 
reauires only one code segment most of the time. 


QENIT uses a minimum date steck and mo extra data sesments. 
All error messaeses are contained in the codes isolated in 2a 
separate code sedment that need mot be resident if you make 
no errors. 


QENIT and the Fourth Frincirle’ Constant DTemasnas 


Most QEDIT commands are so fast that they are over before a 
serious strain has been elaced on the host machine. For 
exame ley 3a 2000-line source Frogram can be searched for a 
string in four seconds. For those orerations which still 
are too much loads QEDIT erovides the abilite to switeh 
Priority subaueuwes dynamically. In faete the sustem manager 
can dictate a maximum eriorits for certain orerstions such 
3s comriles or TEXT and KEEF commancts,. 


QEQIT and the Fifth FPrinciele? Common Events 


The entire desisn of QEDIT is based on the observation thet 
Frogram editing 16 mot comeletely random. When & fFrosrammer 
changes line 250» he is more likely to reauire sgcecess to 
lines 243 throush 265 next than he is to lines 670 throush 
710. This observation dictated the desist of the incdexins 
scheme for the QEDIT workfile,. 


There are many exameles of ortimizing for the most common 
events in QEDIT: the blocksize will hold about 3 screenful 
of data liness built-in commeilers fast renumbering command 
(600 lines rer second) in elace of a GATHER commands, faster 
TEXT’ ins of workfiles than KEEF files (4 to 7 times faster). 


Results of Arrlying the Frincirles to QEDIT 
In less than 7 seconds» QELnIT can text 1000 lines» rernumber 
them and search for 2 strings. Commands gre 80% to 1200% 


faster than EXIT/3000» ferogram size is cut in halfs and cise 
I/O and CFU time are reduced bye up to 90%, 


C-93.8 


OPTIMIZE 


Im order to measure rerformancer an editor-callable 
"erocedure" was written that calculates the elarsed time 
Cusins TIMER intrinsic) and the erocessor time (FROCTIME 
intrinsic) between events. QELIT measured faster than 
EQIT/3000 by these rercentasdes? 


Renumber 1204Z% faster 
List to rrinter 11iSA faster 
Find strings 6134 faster 
Change 6454 faster 
KX @ 6 824 faster 
Text from keerfile 44% faster 
Text from workfile 7334 faster 


The more efficient the Frogranmins of an orerationys the less 
sustem resources it consumes. MPE rrovides a "lLossins" 
facility to record the resource usade of rrosgrams for later 
anaglysis. Both QEDIT and EBIT/3000 were used to rerform 3 
tyrical Frogram maintenance chande Cedity comriley correct 
errors). According to the logsins statisticsy QEDIT reduced 
overhead by these rercentades? 


Physical dise transfers 934 reduction 


lige srace reaulred 87% reduction 
Cru time 724 reduction 
Frogram size 63% reduction 
Total data srace J3% reduction 
lata stack size 43% reduction 


Frosgrammins of QEDIT besan in March 1977 and user-site 
testing in Sertember 1977. At the rresent time (Sertemher 
1978)» there are 20 QEDIT user installations. QEDIT shows 
what can be accomrlished by @errivying all of these ortimizins 
erincirles im the design of one system. In any given 
arrlication system, it may not be rossible to teke advantede 
of all five prrincirless but to whatever extent they can be 
aerliedy the resulting system will rerovide better service 
than it would heave. 


For more information om QEDITs contact me directly: 


Robert M. Green 

Robelle Consulting Ltd. 
#£130-5421 10th Ave. 
eltary B. C. Canada 

VAM 3T9 

Fhones €604) 943-8021 
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OF TIMIZING CASE STUDY #2: APPLYING FAYMENTS 


Im this gccounts receivable systems 247000 invoices rer 
month are Frosted to 107000 customer accounts. The mumber of 
uneaid items rer customer varies from one or two (Ca lot of 
accounts) to 300 (a few maJor accounts). The A/R are 
maintained om an oren-item basis. That iss the invoices 
arrear om the customer’s statement each month until they gre 
matehed ur with &@ Fayment and comsidered reconciled. About 
200-300 cheaues are frosted to the datebase each day. The 
eroplem 16 to sllow the A/K clerks to “arrly" the rayments 
to the frorer invoices im the cheerest rossible manner. 
Certain other constraints exist: the machine is a Series I+» 
only dumb terminals are to he usedy and the system is 
already surrortinsg about 17 terminals and seems fully 
Loaded, 


The comruter sustem cannot tolerate the overhead to sear 
down the chain of records for each account COBGETs) and 
Print them on the screen. There is too heavy 3 load 
already. In additions the software would have to skir over 
Cie@er Gab and isgmore) a larse number of raid invoices to 
find the unmreaiad ones. 


A/K and the First Frincirle$ [tise Accesses 


A/K wses @ database to index entries by gsccount and sort 
them by dates but allows mo on-line urdates to the database. 
They are too slow and too hard to control (Crecover/balance). 
Urdates are only allowed by seauential batch ferograms. 


Fach clerk is Frovided with 2a transaction disc file for her 
“ledger®s containing cories of her active accounts (14 
entries/block). She also has @ rrintout that shows each 
account and sives its location in the file. The disc file 
and associated linerrinter rerort gre rrerared im batch. 

The user accesses this file in on-line mode and converts the 
entries into database transactions. 


The transaction file is accessed im NOBUF mode anc combtains 
only unraid invoices. All on-line activity is done into 
this filey thens at nights those entries which have been 
marked im the file for @rrlication gre retrieved from the 
Gateahase and urdated. 


A/RK and the Second Princirle! Terminal Accesses 

The user inrut syunmtsex allows (but coes not reauire) mans 
individual instructions to be entered in each ineut line. 
This examele arrlies a rayment to seven invoices and writes 


3 small adjustment against one invoice: 


/LABDEFGH»AC1010-101097.50%9C) 
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AmaJor design rroblem was how to refer to the items that 
are om the customer’s account. . The invoice rumber is too 
lons for efficient data entry Cand subject to errors). A 
sequence mumber could have been assigned to each entry on an 
account. Howevery invoices sre mot raid in seauence$ 
eventually, the seauence rmumbers would be as large as the 
invoice mumbers. A auick calculation showed that the time 
reauired to assim mew seauence mumbers was rrohibitive 
(hecause of DK inefficiencies). The scheme settled uron 
assigned relative rosition nmumbers to each unresid item on a 
dynamic basiss but these numbers gre not actually stored in 
the database. In order to shorten inreuty an alehanumeric 
code was used (AsBeCe+eZrAlv..e)d- Im retrosrecty a rure 
numeric seauence number misthht have heen hetter hecause of 
the inreut sreed of numeric keyrads. 


A/RK and the Third Frincirle: Frodram Size 


A/K 16 written entirely in SPL/3000. Stack sizes are modest 
(2K-SK decimal or less)» and only one dise block is kert in 
the stack. SFL rrocedures were created to simulate 2 mini- 
file system for the tramsaction files. The rrocedures cdo 
all ceblocking and dise inreut/outeut. This simrlified 
coding of the three major rrograms. 


A/RK and the Fourth Frincirele? Constant Demands 


There are 3 few srecial transactions that can take up to ~@ 
minutes hut they are very rere and can he ismored. Most 
transsctions sare very shorts and all data is available in 
memoryvy, or 165 one disc read away. 


A/K and the Fifth Frincirle? Common Events 


This Frincirple was errlied heavily to A/R. The most common 
event 165 to @grrly 3 rayment that came in yesterday to an old 
imvoice(s). Alsoyry most accounts have less than 10 
outstanding items. Thereforey this system anticirstes the 
next day’s reauests by creating the batch-file/rrintout of 
all the accounts with an unarrelied rayment. For those 
accounts that reauire attentions but have mo rayments the 
clerk loads them into her batch file on-line (rare). The 
blocksize was ricked so that most accounts could fit im one 
block. 


The tramsaction to arrely 3@ rayment is: 


*10117A67/1AGH 
“Invoice lines 
“Payment mumber 
“Ttiase location of the account (from erintout) 
“Account mumber 
“Fromet Character 
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Sinee starting Froductions we have discovered that usualis 
the account #€ and location #€ entered is Just the one that 
seaquentiaglley follows the last one. Thereforery the sustem 
Will someday be chansted to allow entry of * for next 
account « 


Whem comverting from the manual system to a eure one-Line 
Comreuter systems the ability to write notes on the 
customer’s account card was lost. After @ few monmthss we 
found ourselves under heavy eressure to create new tyres of 
transactions in the system to handle the many srecial cases 
that arose (raid twicey overraidy short-easids took credit 
note twicey @eto.). The original designs onmly sllowed for 
four tyres of transactions? ImMvolcey Faymenby saduustment 
and Journal entry (a larse aciustment with & unieaue mumber 
assigned for comtrol furroses). Rather than clutter us the 
designs we added the ability to write multi-line comments 
for any Journal emtry. With these comments: the A/K clerk 
can mow communicate directly with the customer’s accounts 
Faveable clerk to exelain the erohlem in Enstlish. Since the 
comments are kert in &@ serarate datasets indexed bu the 
wunieue Journal entry mumbers there is mo additional overhead 
On ordinary transactions. 

Basis for future exeansion? since most geccounts Fae im 4 
Simele ratternys the comruter will Cin batch) ere-3geely the 
Fayments when creating the transaction file. Then the 
OFrerator need only take action if the comeuter has selected 
Lnecorrectiy. 


Kesults of Arrlying the Frincirles to A/F 


Tne gerlication maintains 1079000 accounts with 249000 
imvoices rer months usins two ALUM-3 terminals om a CX-%o0o 
With 15-19 other terminals doing less ortimized thinss. AAP 
staff has been reduced from seven reorle to two. At the 
same timers the three terminals used for srosram develorment 
were switched to QEDIT. Resreonse time has agectuaslly ime rover 
on Old @erlications. At the same timer 2 terminals have 
heen added to the system, 


For more information on this examerle of gerelyings oetimizins 
Princirlesy contact the user site directly: 


Gary Nordmany Manaser of Systems Tevelorment 
Malkin & Finton Industrial Surrelies 

29 East Fifth Avenue 

Vancouvery H.C. Canada 

VST LHS 
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APFFENDIX Ai REFERENCES ON HF 3000 OFTIMIZING 


C13 Transaction Processing om the HF 3000 Series III. 

Some HF field System Ensineers have this 
internal HF document which describes the internal 
workings of these software Froducts: 

IMAGE 

KSAM 

FILE SYSTEM 

COBOL. 

FORTRAN 


£2 COMMUNICATOR No. 14. 
Fase 87» Block/Fase mode rroblems. 


£31 COMMUNICATOR No. Le. 
Sedmentation in COBOL 


C41 COMMUNICATOR No. S&S. 
Segmentation for Maximum Efficiency 
of System-Tyre Frosrams. 


C5 JOURNAL -3000 Vol is Noe 6. 
KSAM vs. IMAGE 
HF 3000 with Front-End Processor 
FORTRAN Ortimization 


C6] JOURNAL-3000 Vol. ls No. S- 
QENITT, Quick Frogram Editirnsty 
Small Arretite for Computer Time. 


[7] JOURNAL-3000 VOL. ly Noe 4. 
Usins Extra Data Sesments. 
Common Frogrammins Errors with IMAGE/3000. 


C8 CONTRIBUTED LIBRARY: Vol I/IT, 
IKEA Frogram 
INEALII Frosram 
RESF Frosram 
IMLE Frosram 
FROGSTAT FROGRAM 


C9] CONTRIBUTED LIBRARY, Vol IIT. 
SOO Frosram 
DBREBILEI! Frogram 


C[i0] CONTRIBUTED LIBRARY» "Vol IV*, 


LRSTAT Froesram 
DBCHANGE Frogram 
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Cid SCRUG MEETING LIBRARY» Mareh 1978. 

FASTER - An essay on writings erosrams for 
greater eafficiency. 

QVERLORI (See also SOO.) 

VESTAT ~- Internal efficiency of master 
Habasets, 

SHOWVM - Shows Vvirtusl memroy. 

STACKOFT ~ Stack ortimizinsg routines. 


Cil20 SCRUG MEETING NOTES» March 1978. 
Extra Data Sesments and Process Hancdline 
OQrerator Utilities 


Cis INTERNATIONAL USERS MEETING: 1977, 
KSAM (see extra data segment sizvey loscd times) 
IMAGE for the acivanced User 
Ortimizins FORTRAN IV/3000 
RFG/3000 Frosramming Ortimization 
ate Entry Techniaues 
Segmentation 
MFE II Measurement and Ortimization 
MFE C Measurement and Ortimization 


Ci4] INTERNATIONAL USERS MEETING: February 1975. 
Software Ortimization Throush Sesmentation 


CiSd INTERNATIONAL USERS MEETING: May 1974. 
Frogram Ferformance 


Ciéd CCRUG MEETING MINUTES» Mays 9» 1978, 
IQEA Frosram 
VBMRIVER Frosram 


Ci7] PERFORMANCE GUIDELINES/SERIES III CHF 5953-0533), 
Note the extra load of syunmchronous terminals(s.9) 
and the dramatic increase in the number of 


terminals surrorted when 3a simele file is used 
instead of IMAGE/IIEL/COROL. 


[18] SFL/3000 FOR COMMERCIAL AFFLICATIONS » 


EFFICIENCY WITH EASE OF MAINTENANCE, 
Rerort availahle from Robelle Consulting Ltd. 
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AFFENDIX BS SHRINKING THE STACK SIZE 


The following SFL code can be added to any rFrosgram 

that calls a lot of rrocedures (or subrrosgrams in COROL) 
im order to dynamically ortimize the size of the data 
stack. 


CHECKSTACK LIBRARY SUBROUTINES 


1.Checks for excessive dunmamic stack srace after 
subroutine calls and acdJdjusts the stack sizes consists 
of three routines that are intended to be called 
from the mainline of an arrlication Frogram thet 
HSeS many subrrograms with varying data reauirements. 


2-Contents’ CHECKSTACK1i»s CHECKSTACK2s CHECKSTACKS. 


3+FParameters?: WORKSPACE: 20 butes of slobal data im the 
calling rrograme The erorer COBOL definition is; 


O1 CHECK-STACK~SPACE . 
OS FRINT-RESULTS-FLAG PIC $9(3) COMP VALUE N. 


X N=O(NO PRINTOUT) »1¢ON TERMINAL) » 
x 2(ON CONSOLE) »3(0ON BOTH). 
OS FILLER FIC X¢€18). 


HOW TO USE CHECKSTAR: 


1. Add the WORKSFACE to the data division of your Frogram 
and set the desired FRINT’FLAG value(see ster 4), 


>. At the start of rrogram executions 
CALL "CHECKSTACK1" USING CHECK-STACK-SFACE. 
This call should occur once at the start of the 
mainline. The reurrose is to record the size of 
the dynamic stack area before any subrrograms are 


called. This size is determined by STACK=XXXX in the 
SFREF or RUN commands. 


3. After returning from each subrrogram call; 
CALL "CHECKSTACK2" USING CHECK-STACK-SFACE. 
This call compares the current dynamic stack area 


with the initial size and if it is over S12 words 
larger (1024 butes)» reduces it back to the initial. 
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4. At the end of rrosgram execution: 
CALL "CHECKSTACK3" USING CHECK-STACK-SFPACE., 


This call erints statistics on stack usade on 
either $STILIST or the console or both. Format is: 


GLOB99 STK99 #0K99 AVG99 FATII9OS SIZ99 
~ Global stack size in decimal words 
“~ Initial dynamic stack size 
“~ Number of "OK" subrerosram calls 
Averase stack size rer "OK" call* 
Number of times stack was adiuusted 7 
Averade stack size rer adjusted call ”* 


Start with the default value for STACK= (Cahout 800) 

and a large value for MAXIIATA (20000). If all of the 
subPprogram calls are adjusted (i.e.s OK=0)» increase the 
STACK= value. Try to find a value where most of the 
SUDFrogram calls execute without having to shrink the 
stack afterwards» but mot so larde that there ere no large 
Ssubrrograms left ot adiust, 


INSTALLATION OF CHECKSTAK? 


1. Tyre the following SFL source code into the 
system using QEDIT or ENIT/3000 ane 
create a source file. 


2 Comeile the source file and make corrections 
wumtil there gre mo errors! 


*SFL SOURCE 


3-¢ When you have a successful compiles save the 
USL files usins this command: 


*>SAVE $OLOFASSsUSLSPL 
4, Either COFY the sessment called "LIBSEGi" imto 
the USL file of your arrlication frodram 


Cusina the t{SEGMENTER commands AUXUSL. and COPY) 
or add it to an SL (3SEGMENTER or ?{SYSIDUMF), 
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$CONTROL LIST» SUBFROGRAMsMAIN=LIBSEG1 2 ERRORS=9 
REGIN 


PROCENURE CHECKSTACKT ¢€ BUF ) » 
INTEGER ARRAY RUF » 

BEGIN 

=< DEFINE STRUCTURE/USE OF BUF => 

DOUBLE ARRAY DBUF (X) = BUF,» 


DEF INE 
FRINT’FLAG = RUF + gINITIAL’SPACE = BUF CL) + 
»SHRINK’COUNT = BUF C2)# »OK’COUNT = RUF C3) + 
,OK’SFACE = DIBUFC2)4 »ySHRINK “SPACE = [TIRUF C3) & 


9 
INTEGER ZyrQty 


IF NOT ( O<=FRINT’FLAG¢=3 ) THEN 
PRINT/FLAG t= 13 <<DEF >> 


PUSH (Z9Q)5 Zs=TOSs Qs=TOSs 


INITIAL’SFACE t= Z - Q} 
RUF(2) $= 03 
MOVE BUF(3) t= BUF(2)9(7)3 


ENDs <<CHECKSTACKI => 


FROCEQNURE CHECKSTACK2 ( BUF >) ¥ 
INTEGER ARRAY BUF » 

BEGIN 

“<< DEFINE STRUCTURE/USE OF BUF o> 

IOUBLE ARRAY DBUF (xX) = BUF? 


NEF INE 
PRINT ’FLAG = BUF ¢ yINITIAL’SPACE = BUF C(C1)# 
sSHRINK’COUNT = BUF (C2)# vOR’COUNT = RUF CS) # 
= TIRUF (3) 4 


YOK ‘’SFACE = DRUF (C2) 9 SHRINK “SPACE 
9 

INTEGER Zy» Qy STACKSIZE> 

INTRINSIC ZSIZE% 


FUSH ¢€ ZrQ D¢ Z3=TOSs Qs=TOS»: 

STACKSIZE 3:= Z —- Qs» 

IF STACKSIZE * CINITIAL’SPACE + 312) THEN BEGIN 
ZSIZE ¢( Q + INITIAL ‘SPACE +5 
SHRINK’COUNT ¢= SHRINK’COUNT + 1+ 
SHRINK’SFACE {= SHRINK’SFACE + DOUBLE (CSTACKSIZE) + 
END 


ELSE BEGIN 
OK‘COUNT ¢= OKR’COUNT + 1» 
OK’SPACE $= OK’SFACE + DOUBLECSTACKSIZE >» 
END» 


END <<CHECKSTACK2>> 
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FROCENURE CHECKSTACK3 (¢ BUF) 3 
INTEGER ARRAY RUF 9 


REGIN 
“2 DEFINE STRUCTURE/USE OF BUF 2 


DOUBLE ARRAY DIBUF (x) = BUF> 
QE TNE 


FRINT’ FLAG = RUF # yINITIAL’SPACE = BUF (1) 4 
sSHRINK’COUNT = BUF (C2) »OK’COUNT = BUF CS) 
VOK’ SPACE = DRUF C2) # ySHRINK “SPACE = DTIRUF C3) & 


? 
INTEGER ARRAY FCO338) 3 
BYTE ARRAY FY’ Ok) =F 5 
INTEGER TERMINAL » 
INTEGER GLOBAL “SPACE? 
INTRINSIC PRINToPRINTOFs ASCII sDASCII» WHO, DATELINE} 


IF FRINT’FLAG = O THEN RETURNS 


IF FRINT’FLAG=2 OR FRINT’FLAG=3 THEN BEGIN 
a2 PRINT IDENTIFYING MESSAGE ON THE CONSOLE *: 
Ps=T 93 MOVE FCL)2=Fy (38) 3 
MOVE F ¢="CHECK~-STACK3 "5 
WHOCe v9 FP 7 C12) 9 F C31) 9F% (30) 9s TERMINAL) 3 
MOVE F’C39) 3= "ON®s 
ASCLIICTERMINAL »y LO9F 4 (€42))5 | 
BP’ C2Od TEP 7 C29) ft, 85 
FRINTOFP CF s~-4690) 3 
ENT 9 


Pe=" 85 MOVE PCL) =F se (38) 3 

MOVE Fs="GLOB" » 

FUSH (Q)% 

GLOBAL “SFACE $= TOS3 
ASCII(CGLOBRAL “SPACE »109F/’ (4) ) 5 

MOVE F’°C(10)3="STK"$ 

ASCITICINITIAL “SFACEy109F% (13))3 

MOVE FY C19) S="#0OK 79 
ASCIICON’ COUNT» 109F%(22))3 

MOVE FY C28) 3="AVUG"» 

QNASCIT COR’ SFACE/DOUBLE (OK “COUNT) »109F/’ (31))35 
MOVE F’°C37)2=°#ADI' SF 
ASCIICSHRINK “COUNT »109F’ (41))35 

MOVE FP’ (47) 3="SIZ"3 

NASCIICSHRINK “SPACE/DOUBLE (SHRINK ’COUNT) »109F’% (50) )3 


IF FPRINT’FLAG=2 OR FPRINT’FLAG=3 THEN 
FRINTOR (CF 9-690) $ 

IF FPRINT’FLAG=1 OR FRINT’FLAG=3 THEN 
PRINT CP 9-3690) 5 


END <<! CHECKSTACK3 32 
END <<LIBRARY > . 
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CN-LINE TAPE LIBRARY 


le CVERVIEW 


TAPELIB provides interactive access to information on 
an site’s tape library. It was written te he simple, easy- 
to-use and low in resource usagee Normally, the programs 
would be run aS a job to provide the operator with access 
through the REPLY command. It can also be run in a session 
by System or Account Managers. Information on the single 
sequential file can ke read and updated. The Consoie 
Cperator and System Manager have access to all commands; 
Account Managers use a subset of the commands. Yass 
changes can be made with EDITOR and listings in different 
sequences cah be made with SCRT. 


Commands allow the user to find tapes by number, 
account, account and group, or tape label. The operator 
can find scratches tc be used and can update the library 
to reflect the use. The user can scratch tapes by number 
or find it first by account then scratch ite The Operator 
and System Manager can scratch any tape. Account Managers 
can only scratch tapes belonging to their accounts. 


TAPELIB was designed to be used on a system with 300 
to 490 small and large reels which are used to backup the 
system and store files off-linee The features of TAPELIB 
reflect this design Eut allow tailoring to any tyre of 
systeme 


Three of four digit tape numbers can be used. The 
first character of the tape number can designate the reel 
size by using different ranges of numbers for each size or 
different letters for each size. For example, we use 100 
and 200 reel numbers for seven inch reelse Eleven inch 
reels are numbered 4CO and 500. This system will handle 
a large variety of numbering schemes such as: 


ae Large reels are 0001 thru 1999, small reels 
are 2000 thru 2999. 

be Large reels are three digits with first digit 
even, small reels are three digits with 
the first digit odd. 

ce Large reels only, three digits, many different 
ranges ( use 4& digit tape numbers with a lead- 
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ing zerc ). 


Accounts and grcups are eight characters each. Tape 
labels can be up to sixteen characters. Each tape has an 
associated creation date and sequential reel number, 

LeGe 1 of 3, 2 of 3, 3 of 3. 


When a tape is scratched, a scratch cede and scratch 
date are added to the entry. The data file is ASCII with 
no integer or packed fields, so editing can he done easily. 


TI. THE DATA FILE 


The file is fixed, 


FIELD POS. 
TAPEXO 0 
ACCT 6 
GRP 15 
LBL 24 
CREATEDATE 41 
REELNO 49 
SORN 55 


SCRATCHDATE §&7 


ASCII and 64 bytes. The fields are: 


TAPE CREATION DATE 

REEL NUMBER OF TAPE IN SET 
( 12 = REEL 1 OF 2 ) 

1 SCRATCH TAPE ( S OR BLANK ) 
6 SCRATCH DATE ( or bLANK ) 


LEN. CONTENTS 
4 TAPE NUMBER, LEFT JUSTIFIED 
8 ACCOUNT NAKFE 
8 GROUP NAME 
16 TAPE LABEL 
6 
2 


The data file is created with EDITOR. SET LENGTH=64. 


Tite OPERATING PRCCEDURES 


SESSION MODE: 


The frogram is initiated with :PUN TAPELIB. 
Commands available to the user are 


ALPHA(CAL) 
EXITCEX) 
HELPCHE) 

LABEL EQUALS(CLE ) 
NUMEER (NU) 
SCRATCH(SC) 


JOB MODE: 


LISTS TAPES BY ACCOUNT AND GROUP 
TERMINATES THE FROGRA™ 

LISTS COMMANDS AND DESCRIPTIONS 
LISTS ALL TAPES WITH GIVEN LABEL 
LISTS A TAPE BY ITS NUMBER 
SCRATCHES A TAPE 


The CP entry point must be used to provide a console 
request, so :RUN TAPELIB,OP. 
Commands available to the Console Operator or System 
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Manager are 


LAPGE SCRATCH(1LS) - LISTS 4 LARGE SCRATCH TAPES 
SMALL SCRATCH(SS) - LISTS 4&4 SMALL SCRATCH TAPES 
USE(US) - SAVES SCRATCH WITH NEW LABEL 


IV. CHANGES WITH EDITCR 


When a large number or changes are necessary the ASCII 
file can be TEXTED with EDITCR, even while TAPELIE is run- 
ning in JCB mode. A sample FDITOR session would look like 


this: 
: EDITOR (Note: lines shortened to fit page.) 
/TEXT TAPELIB-DATA,UNN 
/FIND °123"3:KCDIFY 

24 4123 SYS PUE FULL-DUMP 780601 12 S 780620 
MODIFY 24 
123 SyYs PUB FULL-DUMNP 780601 12 S 780620 

RFUTURA TYPE CAILY STCRE 780624 

123. FUTURA TYPE DAILY STORE 780624 
/FIND *"44U8"sh 

221 448 HABAND MAIL EAST-LIST 780522 
MODIFY 221 
Y4U8 HABAND MAIL EAST-LIST 780522 

RS 780624 

448 HABAND MAIL EAST-LIST 780522 S 780624 
/¥Q1 
/EF “400" 

180 GOO NESTER PUB 780413 
/GQ 180/LAST TO 1000 
/CQ FIRST/179 TO 2000 
/GQ 2000/LAST TO 100 
/GQ 1000/LAST TO 400 
/LIST 400. 

KOO GOO NESTER PUB 780413 
/LIST 123 

123 123 FUTURA TYPE DAILY STORE 780624 


/K TAPELIB.DATA,UNN 
/EXIT 


END OF SUBSYSTEM 


The above EDITOR was used 
ber and change theme Then the 


to find a few tapes by nunm- 
tapes were renumbered with 
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the GATHER commande Since our tapes are numbered 100-188 
and 400-490, each grcup was aathered high and gathered 
again low to make the line number and tape mumber match. 
A USE file centainine these commands helps the operator 
text, renumber, and list a few lines tc verify the match. 
From that point, modifying a tape Ly number will get the 
needed line for that tape: see LIST 123 above. 


Ve USING SORT TG GET LISTINGS 


It has been helrful to have alphabetic and numeric 
listing of the tape library tile each Gaye We use two 
sequences: 


1. SORN - major 7% TAPENO 
ACCOUNT 
GROUP 
LABEL 
DATE 
REEL - minor 


the first sequence places all scratches at the end of the 
list then groups the rest of the list by account, group, 
etce The second provides a numeric list by tape number 
for verifying the library. Gutput from the sort gces 
directly to the printer. The SORT parameters are: 


1. f'FILE TAPELIBA;LTEV=LP 
{RUN SORT-PUBeSYS 
D>INPUT TAPELIB.LATA 
POUTPUT *TAPELILA 
PKEY 55,1,BYTE;6,45,BYTE 
PEND 


Ze {FILE TAPELIBSN;TEV=LP 
!RUN SORT.PUB.eSYS 
DPINPUT TAPELIB.LATA 
POUTPUT *TAPELIEN 
>KEY 1,4,BYTE 
PEND 


VI. INSTALLING TAFELIB 
To install TAPELIB use this procedure: 
Number ycur tape library with three or four digit numbers. 


Using EDITOR, key in one entry for each tape; use the format 
in Section II. 
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Use CFETFILF to retrieve TAPELIB.FUK and TAPELIBeJCB from the 
contributed library. 

Deo any of the tailoring listed in Section VII. 

Run the program or stream the jcbe 


VII. TAILORING TAPELIBE 
The current but changable limitations of TAPELIB are: 


name of the tare library file “TAPELIBeDATAeLIB3” 
length of the tape number = 3 
number of scratch tape numbers 

in secrted array = 100 
starting number for small reels “1" and “%2" 
starting number for large reels "4" and "5". 


Each of these parameters can he changed by altering the 
DEFINES and EQUATES in the source file. The imposed limits 
are: 

name of tape library file limited only by MPE 


length of tape number 3 or 4&4 
number of scratches unlimited 
starting number for small 
or large reels up to 5 different digits 


To make changes, find the block of EGUATES and DEFINES in 
the sourcee 
Replace the existing LIBNAME with your library file name. 


Replace the existing contents of LARGENO and SMALLNO with 


the starting digits cf your library. 


If your library uses 4 digit tape numbers, equate TAPENO- 
LEN to 4, TAPENODATEJEN to 10, and SCRSIZE to 10 times 
the equated value of NOSCR. 


If 4100 scratches is too large or too small, equate NOSCR 
to the desired numbere 


Series I users need to set the conditional compile switch 
X1=ON to replace CLOCK and CALENDAR with CHRONOS. 
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SYSTEM PERFORMANCE MEASUREMENT AND OPTIMIZATION 


=o a em ane a oe at 2 Of oe @® oF a8 @ oe om OD O® @® oF OO OP oe @ @® = oe oe & a a men ape’ @ wt ao a ob =o of oF @ ap a =e 


JIM SQUIRES, H-P Systeas Engineer, Fullerton, Ca. 
ED SPLINTER, H-P Systeas Engineer, Los Angeles, Ca. 


Obtaining optimum performance froma a computer system is often 
critical to the success of an installation, This is particularly 
true today when data processing managers are being ask to produce 
more with little or no increase in their budget. 


When most users comment about a system’s performance they are 
really stating how well the system meets their expectations. This 
means that what is felt to be a performance problem might well 
turn out to be an expectation problem. If users fail to consider 
the strengths and limitations of the system while designing 
application programs great disappointaent can result. 


Fortunately performance aeasurement tools formerly used only 
at the factory have matured and are now being distributed to the 
field for SE use. With these tools now available at a point closer 
to the customer, performance problems are being addressed aore 
quickly and in many cases with iapressive results. 


On the following pages is a representative report based on 
one of the machines where performance was judged by the users to 
be unsatisfactory. The report is presented to the customer during 
a aneeting that usually lasts in the neighborhood of two hours, At 
that tine attention is focused on the areas where taprovements§ in 
performance can he realized as quickly as possible. At all tines 
it must be remembered that the object is to optimize the 
combination of the coaputer system and its users not just the 
systen. 
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The purpose of this report is to present an analysis of the 
performance of your HP3000. This information should help in 
answering questions such as: 

1. Is system response time being restricted by CPU, aemory 

or disc contention? 

2, Are any programs unexpectedly dominating the mix? 

3. Can additional applications and/or users be added to the 

system without adversely affecting response? 

4, What might be done to inprove system performance? 


The data presented here was obtained from a trace of systen 
activity collected with the event aonitoring facility, 

A record of each occurence of selected 
events is written to tape for subsequent analysis. For this report 
the primary events monitored are associated with memory aanagenent 
activity, process dispatching and I0 device activity. 


Since data is collected with a aonitor using software traps, 
the aonitoring activity necessarily has an effect on the 
performance of the systea. Experience indicates, however, that the 
results are skewed only slightly and in samost cases is 
undetectable. In any case the information obtained gives one a far 
greater insight into the systen’s activity than is obtainable in 
any other way currently available. 


Raw data is usually collected for a period of time auch 
longer than that chosen for detailed analysis. On a heavily loaded 
system about 500,000 events are recorded on the tape each hour 
activity is monitored. Since detailed analysis is quite tine 
consuming the tape is scanned for a general picture of the 
activity recorded. A 15-30 minute ‘window’ is then chosen for 
‘detailed analysis. 


The operating system of any computer is designed to manage 
the system’s resources, principally, the processor, main menory 
and disc resolving conflicts arising from competition amoung the 
community of users. When deaand for any resource approaches the 
capacity, the management task becomes difficult causing systea 
efficiency to decline. 
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Performance of a system has to be discussed in the context of 
the system workload. The programs which make up this workload can 
be characterized by the type and amount of systema resources 
required for their execution. 


In the following sections this report moves from the general 
to the specific in its investigation of the utilization of the 
three principal resources mentioned above. First, utilization frop 
an overall point of view is discussed, Then @ summary of 
information by programs for all jobs and sessions is presented, 
Next is a detailed report for each program that was found to be a 
significant resource user, The section on conelusions and 
recommendations provides a Summary of the significant bottlenecks 
in the system and suggests ways to improve system performance. 


DATA COLLECTION 
Period Monitored: Mon, Jun 26, 1978 1:32 - 2:23pn 
Total number of events recorded: 461,301 


Window chosen for analysis: 1:53 - 2:i3pm €1200 secs) 


| Unless otherwise noted | 
| ALL TIMES IN SECONDS | 
} ALL LENGTHS IN BYTES | 
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A fairly good first approximation of how well a system is 
performing is given by noting the amount of time the CPU spends in 
each of four states: 


1. CPU busy - the time during which some process was 
executing) 

2. Waiting for swaps - the time during which the aenory 
manager (MAN) is waiting for a dise I/70 to complete and 
no other process has sufficient memory resources to run; 

3. Waiting for disc I/0 - the tine during which a process 
other than MAM is waiting for a disc I/0 to complete and 
no other process is requesting the CPU; 

4. Idle - the tine during which no process is requesting 
the CPU and no process is waiting for I/0 to terminate, 


| | Percent ! { 
| CPU STATE | of Window {| Total Mins t 
i aa a a aa [RSet aa Sarasa s=—-52 [ees eee sesSe=se== [ 
| 1 i | 
i Busy { 74.57 { 14.9 [ 
j Waiting for swaps i 135.31 i 3.1 ] 
] Waiting for disc | 7.87 { 1.6 { 
| Idle wait | 2.25 | 0.5 | 
i | | { 


FIGURE 1-1. CPU usage during the window. The average CPU busy 
interval was 14 ms and the average idle time was S ms. These two 
figures were distorted by the program IDLE. 


The CPU busy time can be broken down as follows! 


Memory manager 10.36% 
Other MPE processes 2.00 
The program IOLE 330.52 
Other user processes 31.69 


Note that the CPU was being used by the memory manager or was 
being held for swapping 25.67% of the time, This indicates that 
the meaory aanager is having considerable difficulty aeeting the 
requests for main memory, 
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OVERALL MEMORY UTILIZATION 


Rs your system is presently configured the resident portion 
of MPE uses 984,464 bytes of memory leaving 439,824 bytes of 
“linked’ memory for Swapping. The size of: resident memory is, to 
some extent, controlled by responses to configuration questions 
while doing a SYSDUMP. 


In analyzing the utilization of memory it is useful to note 
whether the allocation was for code or data and if for code 
whether it came from a program file or a segmented library ¢SL)., 
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| | | | | | | 
| Segmant | Percent | Average | Average | Num of | Overlays | 
| Type | Memory | Alloc | Presence | Suaps {| per Swap { 
[ener nnnn ne [peaenae ses [eae oneess [rereecs=== jerecsese [passereseas | 
| | | | | | | 
| DATA [| 30.75 { 3679 | 8.13 | 4912 | 0.741 | 
| | | | | 
| SL | 44.23 i S272 | 12.47 | 3331 | 1.412 { 
| | [ | { { { 
{ PROGRAM | 8.46 { 4393 | 198.02 | 990 | 0.391 | 
| | | | | 
| Totals | 83.44 { 4327 | 10.41 | 8793 | 0.973 { 
| | I | | | 
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FIGURE 2-1. Memory allocation information. This data applies only 
to linked memory and does not include any segments allocated prior 
to the start of aonitoring. 


The principal concern here is how much swapping went on and 
how many segments currently in menory had to be overlayed to nake 
room for the new one. The nuaber of swaps shown here indicates a 
higher than desirable rate of swapping. There were over 7 suaps 
per second. It is possible to average about 30 dise I/0s per 
second on the HP3000. This means that about 25% of the maxiaum 
possible dise activity was used for gsuapping. 
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OVERALL DISC ACTIVITY 


For best performance, disc 1/0 requests should be evenly 
distributed over the available drives to reduce arm contention and 
seek tines, 


i | | I | Seconds [ 
; | Reaquest | Percent {! Transfer| 2% {| Between i 
| Drive | Count |} of Total | Length |Busy | Requests | 
jaeeaensresee [aensee= ee praseeeeoes jereresse= jaae=- [aaeseeese | 
| | | | | 
| 1 R ; 11171 | 40.1 |} 2924 {23.65{ 0.107 { 
| 1 Ww i 6613 | 23.7 { 3100 [15.52] 0.181 | 
| | | | | | | 
| 2R | 1228 | 4.4 {| 2816 {; 2.80] 0.974 | 
| 2uw { 871 | 3.4 | 1887 {| 1.54{ 1.378 | 
| | | | | | | 
| 3 R | 1596 | = A | 2261 {| 3.57] 0.752 [ 
i 3 YW | sos | 2.9 | 1169 { 1.55{ 1.485 { 
| | | | | 
{ 4R i 11446 | 4.1 | 2244 } 2.19] 1.945 i 
{ 4 | 901 | 3.2 [| 2003 ; 1.635] 1.330 [ 
| | | | | | | 
j 12 R | 1094 | 3.9 {| 3044 { 2.62] 1.993 | 
{ 12 W | 607 | 2.2 | 1673 i 0.99] 1.973 | 
| | | | | | 
{ 13 R ] 1164 | 4.2 { 1632 {| 2.15] 1.027 j 
i 13 WY { 661 | 2.4 | 1338 { 0.93] 1.809 ] 
| | | i | | | 
| | 27860 | | | i | 
| i | | | 
FIGURE 2-2, Global dise activity. The top line for each device 


applies to reads, bottom line to writes. During the window 74.35 
million bytes of data were transferred between disc and memory, 
Swapping traffic accounted for 57.04 million bytes or 76.7% of the 
total. Each second an average of 23,22 disc I/0 requests were 
made. 
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OPERATING SYSTEM DISC REQUESTS 


Certain user activities cause the system to access disc 
storage. It is useful to identify these activities and tabulate 
their respective I/70 loads. The memory manager is almost always 
the system process which uses disc most heavily. All MAM requests 
are associated with swapping. The LOADER accesses program files 
and SL files to resolve external references when the :RUN conmand 
is issued. Other systen processes which access disc memory include 


DEVREC (to verify signon information) and LOG <for systen logging, 
if enabled). 


SYSTEM PROCESSES | USER | 
| DRIVE | MAM | LOADER | OTHER | PROCS | ToTAL | 
[oer == S= | wer re nnn | ene ------ | ----- ---- posse =s45 [Sees —--- == | 
| 1R | 7862 | 853. | 72, «| 2384) | ott 
| 1u | 5466 | 43 2 | 1102 | 6613 
| [ | l | { 
| 2R | 65. | 1 | 123 | 1039 | 4229 
| 2u | | 2 | 43, | 826 871 | 
| | { { [ 
| 3R [| 480 | 95 | 12 | 009 | 1596 
| Zu | 2 | 5 | soi | 809 
| | | i | [ { 
4R | 168 f{ 74 OY 31. || 873 | 1146 | 
qu | 65 | 6 | 930 | 901 | 
[ | { { | | 
| t2R [| 499 J 26 |} 957 | 1094 
| iu f | 24 | | S33. 607 | 
| | [ | | | 
| 13R { 108 | | 15 | 1044 | 1164 | 
f iw | | | 29. | 632 | 661 | 
| | | ( { 
| 14260 | 1185 | 338 | 12077 | 27860 
[| Si.18% } 4.75% | 9.21% | 43.35% | | 


FIGURE 2-3. Operating system disc access requests. The top line 
for each device applies to reads and the bottom line is for 
writes, 
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During the monitoring window of a systea it is possible for 
each user to run one or aore prograas. Figure 3-2 shows which 
programs were run by each user. Also shown are those programs used 
by the operating system. Included for each uger’s programa is the 
CPU, memory and disc resources used. Figure 3-1 contains 
information to help identify users. 


The system prograas listed are run on behalf of users without 
their knowledge or intervention. Normally, all of these prograns 
make small demands on system resources. Since most of these 
prograas are run at a auch higher priority than user prograrns, 
their impact is quickly felt when they become heavily used. The 
fact that MAM used over 104 of the CPU is an immediate indication 
that the operating system is have trouble aeeting the demand for 
memory. There is not enough real meaory to efficiently handle all 
the requests. 


Note the impact that the COBOL compile c¢@#J5> had on the 
system. The combined coapile and prep used 21% of the CPU and 282 
of the aenory during the 6 minutes that the operation took. When 
response times are a problem, COBOL cospiles should be kept to an 
absolute ainiaun. 


The data clearly shows the iapact that the A&4000 processes 
have. With only a couple of exceptions, those processes with more 
than 190 swaps are associated with your application progran. The 
exceptions are significant since they include COBOL and the 
EDITOR. The EDITOR process during Session 41 ran 18 minutes using 
over 7% of the available memory and over 4% of the CPU during this 
tine, 
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| 
| 

#S29 20 MON 1:33P MANAGER. SYS 7 
#534 52 MON 1:35P A40,RON.FMS 
#535 40 MON 1:35P OSSUSER.FMS 
#536 23 MON 1:37° A40,O0SSUSER.FMS | 
| #S37 2? MON 1:37P A40,OSSUSER.FMS 
| #538 26 MON 1:37P A40,OSSUSET.FMS | 
#539 29 MON 1:38P A40,0SSUSER.FMS 
#540 25 MON 1:40P A40, OSSUSER. FMS l 
#S41 53 MON 11:42P GEORGE. FMS r 
l #549 32 MON 1:47P A40,OSSUSER.FMS | 
| #550 31 MON 1:49P A40,OSSUSER.FMS 
| #552 30 MON 1:S0P A40,O0SSUSER.FMS 
| #553 34 MON 1:50P A40,OSSUSER.FMS 
| #555 22 MON 1152P A40,OSSUSER. FMS | 
#S56 51 NON 1:56P ANNIE. FMS | 
| #S57 23 MON 1:57P 240, OSSUSER.FMS l 
| #558 21 MON 1:57P OP.FMS | 
| #560 27 MON 1:59P A40,OSSUSER. FHS 
#S61 46 MON 1:59P A40,OSSUSER.FHMS | 
#564 35 MON 2:02P A40,OSSUSER. FMS l 
#565 40 MON 2:03P OSSUSER.FMS | 
| #567 50 MON 2:04P RONK.FMS 
| #S69 41 MON 2:04P A40, OSSUSER.FMS 
“S71 he) MON 2:12P TOM. FMS | 
| | 
#u 1 10 MON 1:34P IDLE, DAN.FMS 
l #5 5 10 MON 1:50P UCOMPILE,ANNIE.FMS | 
| #J 6 10 MON 1:S6P MANAGER. SYS 


FIGURE 3-1. Session and job identification. 


Figure 3-2 on tha next tuo pages contains summary information 
about each program that was running anytine during the 1200 second 
window, The number of seconds that the program was observed is 
shown in coluan two, CPU usage is shown as a percentage of the 
seconds observed. Memory used is a percentage of aeanory 
available during the time observed. Column five indicates the 
average size of all segments (code and data) allocated for the 
program. The disc I0 count in coluan six applies only to I0s 
associated with files opened by the program. The swap count 
includes all memory manager I0s caused by this program including 
the initial allocation of each segment. Overlays indicate how many 
segments already in memory had to give up memory when the average 
segment for this program was made present. 
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SESSIONS 


29 
34 
35 


36 


=A 
53 


99 
60 


61 


i 
be 


CONMANDS 
SEGDYR 
SEGPROC 
COMMANDS 
R4000 
CONMANDS 
A4004 
COMMANDS 
CORMANDS 
A4000 
A4004 
A4002 
A4003 
EDITOR 
COMMANDS 
EDITOR 
A4000 
A4001 
A4000 
CONMANDS 
A4004 
CONMANDS 
COMMANDS 
A4003 
FCOPY 
FCOPY 
COMMANDS 
COMMANDS 
A4004 
COPYOP 
COMMANDS 
COMMANDS 
A4000 
COMMANDS 
A4004 
COMMANDS 
84004 
COMMANDS 
COMMANDS 
A4003 
CONHANDS 
COMMANDS 
A4000 
COMMANDS 


1197 
182 
185 

1117 
985 
617 
241 
259 
338 


1195 
1197 
1200 
1119 
1143 


1188 
1196 


“CPU 


=> 
© 
ray) 


FIGURE 3-2A. Summary information of each program seen during the 


window. COMMANDS refers to the command interpreter. 


67 EDITOR 
COMMANDS 
EDITOR 
COMMANDS 
A4003 
QUERY 
COMMANDS 
COMMANDS 
FCOPY 
COMMANDS 
EDITOR 


68 
69 
70 


71 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| S COBOL 

| COMMANDS 
| SEGPROC 
| 6 COMMANDS 
| & FORTRAN 
| COMMANDS 
| FORTRAN 
| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 


SYSTEM 


PROGEN 
HAM 
Iosvs 
TOHSG 
LOG 
UCOP 
DEYREC 
PRIMSG 
LOAD 
SPOOLER 
SPOOGLER 


ZCPU 
USED | 


30.52] 
16.47] 
26] 
4.44 
4.48] 
10.981} 
601 
4.30} 


2421 
8650 
30690 
3436 
3297 
3838 
3053 
43513 


| OVER 
SUAPS] LAYS 
81 | .32 
65 | .31 
101 | .26 
16 | .13 
196 |] 1.31 
148 | .97 
110 | .12 
S6 | .50 
43 | .93 
25 | .68 
48 | .83 
26 | .00 
224 | 2.98 
40 | 1.17 
S7 | .91 
42 |} .33 
89 | .58 
81 | .44 
68 | 1.28 
20 | 1.03 
0} .00 
76} Ot 
133 | .02 
91} .07 
174 | .10 
121 | .0S 
29 | .00 
45 | .73 
14] 1.36 
101 | .S2 


FIGURE 3-28. Summary information of each perograa seen during the 


window. COMMANDS refers to the command interpreter for the job or 


session, 


C-10.11 


Programs normally spend very little time actually using the 

CPU. Most of the time- is spent waiting for some event to 
terminate. Three events usually account for the majority of the 
wait tine. 

€1) User requested 1/0, 

(2) Absent code or data segment, 

€3) Human think tiae at a terminal. 
Of course the third item usually doesn’t apply to batch programs. 
In this case waiting for a higher priority process to give up the 
CPU is the third significant event. 


Interactive programas may also be held up waiting for terminal 
output. This is caused by writing large amounts of information 
Ci.e. large forms) to the screen in block mode. Adding aore 
terminal buffers to the system configuration will sometines help. 
Occasionally progranas are seen with significant wait due to 
database or file locking. 


Once the events dominating the wait time have been identified 
it may be possible to iaprove performance of individual progrags 
and thus the system as a whole. When the CPU is the lisiting 
resource, the solution is usually an additional corputer or 
another aore povwerful. 


When absent segaents are responsible for most of the wait, 
performance can be improved by adding more real memory to the 
system. This condition can be caused by segments which are 
excessively large ¢ over 10,000 bytes). In this case reducing 
segment sizes may improve performance to a satisfactory level. The 
cost of modifying programs to accormpolish this aust be balanced 
against the cost of the required additional memory. Frequently 
adding memory is the most cost-effective solution. 


User disc 170 wait time can normally be reduced only through 
reduction of I70 requests by the program. In a few instances 
moving files between drives to balance arm contention may help. 


Locking waits can often be reduced by carefully rethinking 
where and when lock requests are issued. Applications locking 
multiple files ‘or databases> can aake reduction of locking 
contention very difficult. 
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|} PROCESS/ SECONDS USING ABSENMT USER FILE TERM 
{| SESSION OBSERVED CPU SEGMENT DISC IO LOCK READ 


| 

| 

| 
| vs 7 % 7 a | 
| A4000/735 585 3.0 21.1 1.6 2.3 66.8 | 
37 338 3.2 30.3 2.4 14.8 45.7 | 
i 48 1188 0.7 6.4 0.6 17.4 74.4 | 
| S2 1165 0.9 6.2 1.0 17.4 70.7 | 
| 60 737 2.9 13.9 3.7 10.5 53.0 | 
65 522 2.0 19.2 1.5 15.2 58.6 | 
| 84001750 1196 1.0 3.2 1.6 13.4 66.3 | 
| A4002/739 1197 2.7 9.6 3.5 22.3 49.8 | 
| 4003740 1200 0.5 3.5 0.4 0.7 78.2 | 
| ss 626 0.9 6.5 1.6 13.9 74.7 | 
| 64 611 1.3 8.1 1.6 9.6 78.5 | 
| 68 316 2.7 13.9 2.9 15.3 52.4 | 
| 84004736 241 1.3 9.8 1.5 0.0 93.5 | 
| 38 1195 1.4 3.3 2.3 10.7 72.5 | 
l 53 1197 0.0 0.1 0.0 0.0 99.0 | 
| 57 992 0.3 1.0 0.4 0.0 97.8 | 
61 30 3.2 27.9 1.4 0.0 27.2 | 
61 64 4.4 33.2 5.9 0.0 42.9 | 


FIGURE 4-1. Program wall-time distribution. This chart shows what 
Was happening to programs curing the tine aach was being cbhserved. 
For instance, during the S83 seconds that program A4000 (#S35) 
was visible within the window it spent 3% of that time executing, 
21.14 of the time waiting for a segment to be made present before 
execution could continue, 1.6% of the time waiting for file I/Os 
to complete, 2.3% of the time for a data-base lock and 66.8% of 
the time waiting for response from a terminal read, 


The following processes spent a significant amount of tine 
waiting for “blocked I/0’. This is caused by writing to a terninal 
when terabufs are unavailable or by nobuf I/0, The largest factor 
in this case is probably due to the nobuf I/0 calls issued by 
IMAGE. 


A4000/60 13.642 
R4001758 11.70 
A4002739 16.57 
A4003740 14.41 
A4003768 10.06 
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{ Progran: &4000 #S35 OSSUSER.FMS i 
i Observed: 13:36:40 - 14:02:45 3835.4 secs | 


| pone rene nn nnn nn semen nnn wenn nn ceca nemo sn nn neon esernacsasae soos | 
[ {| OCCURRENCES |SECS BETWEEN] AVERAGE | CPU [ 
{| WAITING FOR: | PRCNT COUNT | OCCURENCES | WAIT {BETYEEN | 
Grobtonignntag ea feseeee eres I goer eoaeea=| shee s=2= [erate 
{| ABSENT SEG ; 45.15 S21 | 1,123 | 237 | 0.034 | 
|} DISc 1/70 | 22.70 262 | 2.233 | -035 | 0.067 | 
| TERM READ | 16.90 193 | 2,996 | 2.005 {| 0.097 | 
| HIGHER PRI j 12.31 142 | 4.120 | .021 | 0.124 | 
| MPE RESOURCE ;} 1,47 17 | 34.240 | .3390 | 0.994 | 
| TERM WRITE | 4.21 14 | 41,522 | 1.480 | 1.204 | 
| DATA BASE LOCK | »26 3 | 180.617 | 4.562 | 3.281 : 
| emo eee ewe am am aa me > am a Om oe O88 Oe Oe Ow ow OD ot we OD oD oe oe ee Oe a oe =e an ae om oe oe OOF SO BST SZ eB Serene oe wawe aw 

| MEMORY AND SWAPPING LOAD: ( 
| 
| MEMORY USED TINE IN MEMORY OVER | 
i PRCNT AYG SIZE AVERAGE TOTAL SUAPS LAYS | 
Pocewec an, ee acarenecceenes  enaecaea——a= |! 
|} STACK97 1,908 7816 13.099 332.1 22 1.772 | 
| DSEG100 »002 7872 .701 i a 1 2.6000 | 
} OSEG1O1 e002 7640 -668 6 t 5.000 } 
| DSEG104 .006 79592 2.149 2.1 1 3.0900 | 
| DSeGsd 004 3440 1.935 1.9 1 2.000 | 
| OSEG?74 »120 9026 6.621 $9.5 9 333 | 
| DSEG9S .1835 2216 7.958 214.8 2? .000 | 
| OSEGS4 0177 1464 10.385 311.35 39 »000 | 
| [ 
| Avgs for 28 [ 
| data segs 2.018 2333 6.655 233 6206 | 
| | 
| Avgs for 44 | 
{| SL segs 10.643 6714 13.472 296 2.311 | 
| | 
|} Avgs for 1 { 
| prog seg » O11 3904 7.357 1 .000 | 


FIGURE 4-2, Process detail. This illustrates the level of detailed 
information available for each process active within the window. 
Events which caused the process to wait are listed at the top in 
order of number of occurrences. Note that this process used only 
67 as of CPU tine between each disc 1/0 which occurred on the 
average every 2.2 seconds. 

While the data here indicates a terminal response time of 
991 ms Ctinae between reads ainus wait for read> actual response 
time was around 135 secs. The difference is caused by anultiple 
reads being issued for a formatted screen. 
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The data presented in this report indicates a couple of 
reasons for your reduced response time. The mamory manager is 
having trouble meeting demand for main memory. This is shown by 
the fact that MAM used over 10% of the CPU during the window, A 
Swap rate of over 7 per second is another indication. 


The memory contention problem can be reduced to some extent 
by reducing the size of the five large SL segments used by you 
application program. You should be abte to identify these using 
the individual program data sheets in Section IV. 


The second problem is database locking contention. Data in 
Section IV shows that most executions of your application spent 
about 15% of the time waiting to lock databases. This problena was 
particularly severe for A4002 €#S39) which spent over 224 of the 
time waiting for database access. No suggestions can be made here 
since a solution, if available, would require intirnate knowledge 
of the application. 


The information presented in Section III shows the impact of 
program development activity. Note the CPU and memory usage during 
executions of EDITOR, FCOPY and COBOL. When response times become 
unbearable, it may be necessary to curtail on-line program 
development. 


During the 30 ainutes that data was being collected 34 
log-ons occurred, Since the log-on process places a heavy load on 
the system, even though for a short time, an atteapt should be 
made to reduce this activity. At least 29 sessions lasted less 
than one minute, 


An effort 
should be made to keep at least 20,000 free sectors on the systen 
disc. At least 12-15% of the total disc space should be free at 
all tines. Theory and experience both show that when the average 
utilization of any resource approaches the capacity, a large 
performance degradation results, 


Data in Section IV seems to indicate that when the memory and 
locking bottlenecks are removed, it is unlikely that another 
“bottleneck” will be uncovered. Alaost certainly the CPU will not 
restrict you for the foreseeable future, Disc activity level is 
low enough to suggest no problem will occur here either. 
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There are several. programs aore or lesg available that in 
some way provide information pertaining to performance. fFlany are 
contributed and thus may or may not execute properly with the 
lastest release of MPE. The programs marked as contributed are in 
general circulation but have not been formally placed in the 
contributed library. 


1. MONITOR the combination of a software monitor built into 
MPE and a data reduction program. This is the most 
complete performance tool available. Output from 
the reduction progranr requires careful 
interpretation. Dedicated tape controller and drive 
required. Available only to SEs. 


2. SAMPLER® used to identify those sections of code which are 
executed most frequently. Requires installation of 
an additional clock board on the system to be 
sanpled. Dedicated tape controller and drive 
required. Available only to SEs. 


3. TRACER™ measures segment boundary crossings to determine 
which segments are referenced and how often. Can 
not be used with COBOL programs. Oedicated tape 
controller and drive required. Available only to 
SEs. | 


4. TUNER2 shows current and maxinum use of several systen 
tables. Used to determine whether configuration 
parameters have been correctly chosen. Contributed, 


3. OVERLORD useful in determining who is executing what progran 
and the corresponding stack size. S00 ‘Son of 
Overlord) provides the same functions. In the 
contributed library. 


6. SHOWVM indicates, at a gross level, how real and virtual 
memory is being used. Helpful in deterrmining how 
much aenory a particular prograa uses. In. 


contributed library. 


7. SHOWQ a system command which displays information about, 
process scheduling subqueues. If the rightaost of 
the three coluans displayed grows longer than the 
center coluan, then the systea has insufficient 
real memory for the current load. 


* General availability currently scheduled for early 1979. 
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11. 


13, 


14, 


1S. 


16. 


17, 


18, 


FREE2 


SYSINFO 


PROGINFO 


KSAMUTIL 


LOG FILES 


LISTFXX 


DBDRIVER 


IDEA 


DBSTAT 


LISTDIR2 


LISTF 


displays the amount of free spece on alls systen 
disc packs and indicates how fractured the space 
is, Badly fractured dise space can cause a 
considerable performance degradation. HP supported 
system utility. 


prints system configuration information without 
doing a SYSDUMP. Contributed. 


prints stack size, segment size and external 
reference information about program files. AN 
extended version of PROGSTAT. Contributed. 


displays blocking factors and intrinsic call counts 
associated with KSAM files. HP supported utility 
delivered with KSAM, 


contain information associated with log-ons, file 
closes and I40 transfer counts by process. Some 
contributed prograas available to reduce 
information in these MPE generated files. 


used to carefully track use of disc space, 
Indicates location of first extent of each file and 
date of last access in addition to other 
information. When used in conjunction with FREE2 
the amount of recoverable lost disc space can be 
calculated. In the contributed library, 


used to quickly obtatn information about an IMAGE 
database such as the size of the DBCB and 
individual transaction times for a single user. 
Distributed with IMAGE but is unsupported. 


helps determine performance Characteristics of an 
IMAGE based application. Can measure the effect of 
multiple users. Timings apply only to the IMAGE 
response times, not application processing times. 
Contributed. 


determines length of synonym chains in IMAGE master 
data-sets. Long synonym chains can cause dreadful 
performance degradation. Contributed. 


used to determine location of the first extent of 
disc files. HP supported system utility. 


The ‘“-1° option displays the file label which 
contains the address of each extent of the file. 
Output can be written to a disc file for subsequent 
programatic processing. HP supported MPE comaand. 
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The aaount of memory reserved exclusively for MPE is referred 
to as fixed memory as opposed to linked meaory for which all 
processes compete. The size of fixed memory can have a substantial 
effect on performance of aachines with Less than Si2kb of memory. 


SIZE ( 
| FIXED MEMORY GENERAL LAYOUT BYTES ITEM | 
Wes gececg crs wesc cr c= scan ena a | 
| Driver linkage table 256 | 
| CST block table {32 * 30 { 
{| Bank table 192 | 
{ Job process count table 88 i 
| Systema global area 768 { 
| Data segment table 3072 * 4 i 
| Code segment table 1536 * 2 | 
| Code segment table extension 4000 * 3 ( 
{| Process control block table 4096 * 3 i 
] Interrupt control stack 1088 * 10 ; 
| Terminal buffers 4112 * 7 | 
| I70 queue 2832 * 6 | 
| Interrupt linkage/Device info table 6520 ] 
| Syster buffers 4664 * 8 { 
{| Working set table 4464 * 30 ( 
| Memory managernent table 3840 * 9 i 
| Virtual bit map 912 { 
| Virtual disc space locator 768 | 
| Logical-physical device table 328 | 
[| Timer request list 456 * 12 ( 
| Job cutoff table 424 { 
| Systen internal resource table 440 [ 
|] Breakpoint table 320 * 13 { 
| Memory management code 10200 | 
| Miscellaneous systea routines 3272 ( 
| System clock & timer req list code 3304 | 
| Resident I[0 code 12064 | 
| Internal interrupt handler code 1880 [ 
| Dispatcher code 1376 | 
i Disc driver code 2424 : 
| Tape label input buffer 592 | 
| Hiscellaneous areas 7900 ( 


FIGURE B-1. Items in fixed memory of the 2%b system at the 
Fullerton HP Technical Center listed in approxiaately the sequence 
they actually appear in amenmory. Lines with asterisks indicate 
segments whose size is directly affected by responses given at 
SYSDUHP time. The item numbers are references to Appendix C of the 
System Manager Manual. 
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SEMI-RESIDENT SYSTEM CODE 


In addition to the 60-90kb of fixed memory several MPE 
segments are referenced so frequently that they tend to spend auch 
of the time in memory. On the average 3000, APE is probably 
holding at least 150kb of memory at all tines, Since this is not 
affected by the total amount of memory on the system adding aore 
memory to systens in the 256-Si2kb size -can substantially improve 
performance, 


The following system code segaants tend to spend at least 75% 
of the time in memory: 


FILESYS] $9352 FREAD, FWRITE 

FILESYS1A 3400 FILESYS suppert rcutines 

FILESYS2 9624 FPOINT, FCONTROL, FUPDATE 
FILESYSS 4208 FILESYS support routines 

FILESYS6 3472 PILESYS support routines 


Other code segments which spend over 60 percent of the tine 
presant: 


ALLOCUTIL 3848 Cevice allocation utilites 

PINT 3048 CALENDAR, CLOCK, Process support 
DATASEG 3040 Data segnent handling routines 
CHECKER 1536 GETPRIVMODE, Intrinsic errors 
UTILITY! 3208 ASCII, BINARY, WHO, READ, PRINT 
IOTERMO 9128 Terrminal driver 


23808 Tota’ oytes 


Some MPE data segaments which nd to stay in memory = are 
listed below with a typical size in vords, 
UCOP request queue 208 
LOEY table 2328 
Disc directory seg 2056 
Job master table 1024 
Volume table 200 
FMAYT 528 
Process/job xref 264 


7208 Total bytes 
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| | Total | Num|Global| STACK | MAX | SL | SL | Tot | 
| Program | Words |Segs| DB-QI} QI-ZIj{ DATA heb ec : 
orien ae [ena nnn n= fonnn focecnn [oecane feecccee beret boron ns fore 

| APL | 138520 | 49 | 6883 { 1024 } 31000 j 2% | 480124 70 | 
{ BASIC 1 41564 | 24 | 496 | 808 { 31000 | 24 | 53344] 48 | 
| BASICOMP | 33184 | 18 | 1146 | 806 | 30000 {| 15 | 37756{ 33 | 
{| COBOL f 84892 | 35 | 3953 | 2000 | 32000 | 18 | 41212] 33 | 
|} EDITOR { 33380 | 15 j 995 | 4600 | 8000 | 17 {| 39680] 32 | 
{ FCOPY ; 16080 | 5S | 4893 | 800 | 31000 | 19 | S03G4| 24 | 
{ FORMAINT | 7088 | 2 | 1722 | 800 | 20000 | 10 | 23199] 12 | 
| FORTRAN | 45188 | 21 | 1701 | 2500 | 32767 | 16 | 36124] 37 | 
| FREE2 i 696 | 1 | 4172 | 800 | DFALT { 10 | 23048; if | 
| LISTDIR2 | 8936 | 4] 795 {| 800 | 8192 | 16 { 42460f 20 | 
{| LISTEQ2 | 1012 | 14 | 2487 | 800 | 15000 | 3S | 12800] 6 | 
| MERGE ; 2836 | 1 | 2] 900 { 15000 {| 15 | |} 16 | 
| MPMON i 2956 | 1 | 5524 | 800 | DFALT | 13 | 16 | 
| MRJE | 20488 | 7 | 3221 | 800 | DFALT | 19 | 42540| 26 | 
| MRJENON | 1860 } 2 | 394 4 1100 | S200 | 23 | $2208] 25 | 
| MRJEOUT | 1816 | 2 | 2306 | 1024 | DFALT | 12 | 29352] 14 | 
{ QUERY | 42820 | 20 | 4174 | 1300 | 11000 | 28 | 62684| 48 | 
| RESTORE | 1949 } 1 | 2413 | 800 | DFALT | 8 | 20404] 9 | 
{ RJE ( 5400 | 8 | 927 | 1000 | DFALT | 24 | 32 | 
{| RPG {| §5396 | 22 | 3146 { 800 | 32000 | 1S | 37604] 37 | 
{| SEGDYR i 1028 j| 1 | 369 | 800 | OFALT { 3S | 10488] 6 | 
| SEGPROC | 12676 | 10 | 905 | 1000 | 24000 f 19 | 41828] 29 | 
{ SORT i 2976 | 1 | 1 | 800 | 15000 | 14 | 36026] {5 | 
{ SPL | 40628 | 30 | 3290 | 2500 | 32767 | 16 | 36124] 46 | 
| SPOOK | 7404 | 3 | 1791 | 800 | 30000 | 1? | i; 20 | 
| SYSDUMP | 16092 | 3 | 3425 | 1000 | 16000 | 22 | | 27 | 
| | | | l i I 
| | 626884 |299 | | | ( | l | 
FIGURE B-1. Listing of HP software showing the size of the prograa 


$size 
initial stack is shown along with the maximum size it may 


in words and the number of segaents in the program file. The 
of the 


grow to. SL segs refers to the number of SL segments that are 
directly referenced by the program file. These segments may in 
turn reference other segmants. The sum of the length of all 


directly referenced SL segments is included under the heading SL 
words. Total segments is sinply the sum of the program segments 
and the SL segments. 
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} MPE USE OF SYSTEM DISC | APPENDIX C { 
| | | 
SYSTEM DISC LAYOUT 
APPROX 

USE OF DISC SPACE SECTURS 

Disc label 1 

Defective tracks table 4 

Cold load information 22 

Free space table 32 

System directory 384-6000 Cconfigurable> 

Virtual mamory swapping area 1024-32767 Cconfigurable) 

System files and tables 7300 


User file area 149,000 - 187,000 C7920) 


System software uses about 15,000 sectors of the user area. 


On non-system discs (other than private volumes) the only 
overhead is for the disc label, the defective tacks table and the 
free space table. All other space is available for user files. 
Master volumes of private volume sets will have a file directory 
using 1000 - 4000 sectors. 


Drive type Tracks Sectors Bytes 
7906 1,600 76,8090 19,660,800 
79290 4,075 195,600 99,073,600 
7925 7,335 469,440 120,176,640 
PUB.SYS DISC SPACE 
FILE SECTORS FILE SECTORS FILE SECTORS 
APL 1201 FORTRAN 384 QUERY 383 
BASIC 349 FREE2 43 RESTORE 490 
BASICOMP 231 INITIAL 400 RJE 61 
CICAT 2785 LISTOIR2 84 RPG 472 
COBOL 718 LISTEQ2 32 SEGDY¥R 16 
COMMAND 2901 MERGE 29 SEGPROC 118 
DPAN2 297 MPMON 73 St 90901 
EDITOR 284 MR JE 195 SORT 30 
FCOPY 174 MR JEMON 24 SPL 362 
FORMAINT 76 MR JEOUT 40 SPOOK 79 
SYSOUMP 162 
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All HP7900 family drives have a 937.3 kb/sec data transfer 
rate and all have identical seek times of 5 me track-track, 25 as 
average random and 45 as typical fall stroke. The 7996 and 7920 
each have 48 sectors/track with a 8.3 as average rotational delay. 
The 7925 has 64 sectors/track with an average rotational delay of 
11.1 os, 


On the average, the HP3000 is capable of completing about 30 
disc transfers per second. If a program has exclusive use of the 
system and is reading sequential sectors without buffering, as 
many as S8 transfers per second may be achieved. A prograa 
randoaly writing sector size blocks to a large (115,000 sector) 
file aight see a transfer rate on the order of 20-24 transfers per 
second. Swapping activity must be considered since it will use 
some of the 30 transfers available each second. 


Yhen a user reads ae record, the data will be returned in 


about § milliseconds if the logical record is already in a bufferim 
mem i 


TERMINAL I70 CONSIDERATIONS 


Every character passing to or froa a terminal connected to 
the 3000 through the ATC (asynchronous terainal controller) causes 
a CPU interrupt. This is true whether the terminal is strapped for 
character, line or block mode. This can cause performance problens 
when the aggregate character rate approaches 2000 per second. 
While this indicates only 8 terminals can be sinultaneously 
transferring a constant 240 characters per second, this is in fact 
very difficult to achieve for aore than one or two seconds at a 
time. 
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1. Keduce unnecessary logons. 
2. Allocate often used program files. 


3. Keep segment sizes under §$,000 words. 
Are any process stacks larger than necessary? 


4. Check for file or database locking conflicts, 


>. Will primary paths help database access? 
Are their long sort chains? 
Are there long synonya chains? 
Are any master data-sets more than 80% filled? 
Ara all IMAGE DBCBs as small as practical? 
Use "*" in Image item lists whenever possible. 


6. On-line program development team should use the textfile- 
masterfile’ technique to reduce Text and Keep overhead. 


?. Maintain sufficient free dise space. 
7 Is there at least 15,000 free sectors on tha system disc? 
Is at least 10% of the total disc space free? 


8. Sorts invoked from inside programs may run slower because 
less stack space is available for workspace. The stack 
may be left much larger than necessary for the rest of the 
program execution tine, 


9. Data files with high access rates should be evenly 
distributed over available drives. Program files with high 
swaps rates should reside on fast drives. 

10, Keep system tables feascnabiy configured, 


13. Are too many batch jobs executing concurrently? 


14. Do any processes have more files open than necessary? 


15. Are KSAM file blocking factors optinua? 


16. Are any programs making excessive use of DEL edits? 
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USING EXTRA DATA SEGMENTS: SAFE AND EFFICIENT 


Rick Ehrhart 
Hughes Aircraft Company, El Segundo 
M/S 335/510 
P.O. Box 92426 
Los Angeles, CA 90009 
(213) 648-0755 


Abstract 


Handling extra data segments on the HP 3000 has given rise to 
numerous lectures, papers and classes. The methodology has always been 
to use the data segment '"DS'' intrinsics with the extra data segment 
"DS" capability. The purpose of this paper is to demonstrate a new 
methodology, one using the privileged "PM" capability. 


Introduction 


There are two types of data segments on the HP 3000; the stack and 
the extra data segment. There is one and only one stack for each 
process to utilize the data in a predefined structure. The extra 
data segment,on the other hand, can be utilized by one or more processes 
in a user defined structure. It may be used as a table or an area for 
process-to-process communication. 


For most applications, the "DS' instrinsics are quite adequate, 
but when the programmer is dealing with system level processes, the over- 
head of the "DS'' intrinsics is unnecessary. This paper will show how 
to use three very powerful and privileged assembly level instructions 
that work on data segments: MIDS, MFDS, MDS. 


Techniques 


To acquire an extra data segment, the programmer still must use 
the GETDSEG intrinsic. In non-privileged mode, GETDSEG returns a 
logical index; but in privileged mode, GETDSEG returns the Data Segment 
Table Index or ''DSTX'"'. This value is the unique index for the extra 
data segment that the process acquires. All data segments, whether a 
stack or an extra data segment, have a unique DSTX. The DSTX must be 
saved for all further operations. 
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To move data into the extra data segment from the stack, the 
programmer uses the "DS'' intrinsic DMOVOUT. DMOVOUT checks the 
boundaries of both the stack and the extra data segment and then moves 
the data out from the stack to the extra data segment. However, in 
privileged mode, the programmer doesn't have to use DMOVOUT, he/she 
may use the assembly instruction MIDS, Move To Data Segment. This 
one instruction moves words from a DB-relative location to the extra 
data segment starting at a specified offset for a count. Usage is 
Straightforward and simple. Example One has a procedure that shows how 
to use the MIDS assembly instruction. Basicly, the following items are 
pushed onto the top of the stack: target DSTX, the one returned from 
GEIDSEG, the target offset, the source DB-relative address, where the data 
is in the stack, and a positive count of the number of words to be moved. 
The one drawback is the fact that the programmer has to make sure that the 
DSTX, the offset, the DB-relative address, and the count, are all valid. 


To moye data into the stack, the programmer used to call DMOVIN; 
but now the programmer may use the second privileged assembly instruction 
MFDS, Move From Data Segment. This instruction expects the following 
values on the top of the stack: the target DB-relative address, the 
source DSTIX, the source offset in the DSTX, and a positive count. To 
see how to use the MIDS instruction, please see Example Two. 


The third privileged assembly instruction is MDS, Move using Data 
Segments. It moves data from one data segment to another. This instruction 
requires the following values on the stack: the target DSTX, the target 
offset, the source DSTX, the source offset, and a positive or negative 
count. Please see Example Three for usage. 


To release the extra data segment, the programmer uses the FREEDSEG 
intrinsic. The DSTX returned from GETDSEG is used as the index. The 
process has to be in privileged mode to call FREEDSEG. 


Conclusion 


It is highly recommended that the programmer read the HP 3000 
SERTES 2 MACHINE INSTRUCTION SET REFERENCE MANUAL, Part. No. 30000-90022 
before attempting to use these privileged assembly instructions, since 
with these instructions, the programmer has a chance to destroy the system's 
integrity in one swift blow. For example, if the DSTX is invalid, the 
system will come to a halt with system failure 16; or if the DSTX is 
wrong, the instruction could overlay another user's stack or even a system 
table. 


The above techniques do cut down on overhead when working with extra 
data segments. This is very useful for critical systems like a commumni- 
cations system, on-line monitor, or where processes have to communicate 
very quickly. These techniques have been used at Hughes Aircraft Company 
quite successfully, and the benefits are well worth the dangers. 
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<<kt>> aeiba ONE <ced> 
Eq€ Cee ,~eaewrowneneweernwew asequ nw ewron er eee ee wees Bene eB awe se Zee we wea ow wesw 2S > 
<<>> PRUCEDURE HOVE! TO'XDS (TARGET !DSTX, TARGET! OFFSET, SOURCE, COUNT)? 
VALUE TAKGET'DSTX, TARGET! OFFSET,SOURCE, COUNT? 
INTEGER TARGETIDSTX, TARGET! OFFSET, SOURCE,COUNT} 
OFTION PRIVILEGED) 
BEGIN 
TOS ss TARGETICSTX} 
TOS $= TARGETIOFFSET? 
TOS 3s SOURCE} 
TOS ss COUNT; 
ASSEMBLE (MIDS 4)} 
ENDs << MOVE'TO'IXDS >> 


<<tx>> EXAMPLE TwO <<xx>> 
€ Cem Awe ZB FBZ we Z wan Ze we BeBeonZ eZ nD awwee Fevwve pes an eee NReunnwe seen ewe ow >> 
<<>> PROCEDURE HOVE !FROM'XDS (TARGET, SOURCE! DSTX, SOURCE! OFFSET, COUNT) 3 
VALUE TARGET, SOURCE!DSTX,SOURCE!'OFFSET,COUNTS 
INTEGER TARGET, SOURCE 'DSTX, SOURCE! GFFSET, COUNT; 
OPTION PRIVILEGED? 
BEGIN 
TOS ¢= TARGET; 
TOS ss SGUKCE!DSTX} 
TOS $= SOURCE!’ OFFSETS 
TOS $= COUNT? 
ASSEMBLE (MFDS 4)} 
ENDp << MOVE'FROM'XDS >> 


€<xk>> EXAMPLE — <<xx>> 
/_ €<wee_weseeznveawrewene wpa nee re eweaeww hd de ee ee Penn eee me em mo ?> 
<<>> PROCEDURE MOVE'XDS(1ARGET!DSIX, TARGET!OFFSET, SOURCE! DSTX, 
SOURCE'OFFSET,COUNT)} 
VALUE TARGET'DSTX, TARGETIOFFSET,SOURCE'!DSTX,SOURCE!' OFFSET, COUNT? 
INTEGER TARGET'OSTX,TARGET!OFFSET, SOURCE!'DSTX, SOURCE! OFFSET, COUNT} 
OPTION PKIVILEGED} 
BEGIN 
TOS = TARGET'DSTXS 
- TUS ss TARLETI OFFSET} 
TOS += SOURCE'DSTX; 
- JOS ss SOUKCE'OFFSET} 
JOS 3s COUNT? 
ASSEMBLEC(MDS 5)} 
ENDz; << MOVE!XDS >> 


C-ll. 3 


<<tt>> EXAMPLE ONE <c¥sor 
€¢€e2e ,ow ete eed oe ede deed A od ne ho ee we s2ew 2> 
<<>> PRUCEDURE MOVE! TO'IXDS(TARGETIDSTxX, TARGET! OFFSET, SOURCE, COUNT) } 
VALUE TAKGET'DSTX, TARGET! OFFSET, SOURCE, COUNT? 
INTEGER TARGET'DSTX, TARGET'OFFSET, SOURCE,COUNT} 
OF TION PRIVILEGED? 
BEGIN 
TOS $3 TARGETICSTX} 
TOS $= TARGET!IOFFSET} 
TOS 3s SUURCE} 
TOS ss COUNT; 
ASSEMBLE(MIOUS 4)3 
END, << MOVE'TOIXDS >> 


<<t%>> EXAMPLE JTwO <<xx>> 
a Tada Sa eee kneaded edad Rad Fok ok te ee oe ee ee ee aL -m2se2=a>> 
<<>> PROCEDURE MOVE! FROM'XDS(CTARGET, SOURCE 'DSTX, SOURCE! OFFSET,COUNT)s 
VALUE TARGET, SOURCE'DSTX,SOURCE'OFFSET, COUNT? 
INTEGER TARGET, SOURCE 'DSTX, SOURCE! OFFSET, COUNT} 
OPTION PRIVILEGED? 
BEGIN 
TOS $= TARGET} 
TOS s= SOUKCEIDSTX} 
TOS §= SOURCE!OFFSET} 
TOS $= COUNT? 
ASSEMBLE (MFDS 4)}7 
END; << MOVE'FROM!XDS >> 


<<xkt>> EXAMPLE eile <<xa>> 
€ Cem ween eer en ewe peter neem nme awe nent ne weer neem anne >> 
<<>> PRUCEDURE MOVE'XDS(1ARGET!DS1X, TARGET! OFFSET, SOURCEt DSTX, 
SOURCE'OFFSET,COUNT)} 
VALUE TARGET!DSTX, TARGET'IGFFSET,SOURCE!'DSTX, SOURCE'OFFSET, COUNT? 
INTEGER TARGET'OSTX, TARGET!OFFSET, SOURCE! DSTX, SOURCE'OFFSET,;COUNT# 
OPTION PRIVILEGED? 


BEGIN 
TOS s= TARGET'DOSYX} 

- TUS se TARLET'OFFSET? 
TOS 32 SUURCE'OSTX; 

- JOS ss SOUKCE'OFFSET;? 
TUS 3= COUNT? 


ASSEMBLE(MDS 5)3 
ENDs << MOVE'XDS >> 
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ve 


INSTALLATION MANAGEMENT 


Series "Dp" 


INSTALLATION DES TIGQN 


ee 
=——e neem eT eM SKS SS SSS SS SE SKE STR SEB Se tsetse se 


SSS SST RZ SSS SS BSS SP ts ets set ee eee ee we eee ee Lee 
—— mm wwe SSK SS SKE KS SSS SSS SS SSS SHE Ss Ess sess ce 


Longs Drug Stores: an example 


Dy: Bill Gates 
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LONGS DRUG STORES, INC. 


114 STORES LOCATED IN CALIFORNIA, HAWAII, ALASKA AND ARIZONA 
$550 MILLION SALES IN FISCAL ‘78 
5200 EMPLOYEES 


DECENTRALIZED OPERATION - NO CENTRAL WAREHOUSES 
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ONE 


TWO 


TWELVE 


HARDWARE CONFIGURATION 


HP5000 SERIES II MODEL 9 WITH: 


NE 
ONE 
THREE 
TWO 
THREE 
ONE 
THO 
ONE 
TWO 
QNE 
24 
TWO 


512 BYTES MAIN MEMORY 
HP7905 SYSTEM DISC 

HP7905 SPOOLER DISC 

47M BYTE ISS DISCS 

223M BYTE TELEFILE (AMPEX) DISCS 
1600 BPI TAPE DRIVES 

1250 LPM LINE PRINTER 

200 LPM LINE PRINTERS 
HP2635 SYSTEM CONSOLE 

Tl 743 HARD COPY TERMINALS 
DIABLO HARD COPY TERMINAL 
HP2640 (44) CRT TERMINALS 
SELECTOR CHANNELS 


HP2100 DOS-TCS SYSTEMS WITH: 


ONE 
14 
ONE 


4M BYTE DISC (EACH) 
HP2640 CRI-TERMINALS (EACH) 
1600 BPI TAPE DRIVE 


DATAPOINT 1500 DISKETTE TERMINALS 
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APPLICATIONS 


ACCOUNTS PAYABLE - 7000 INVOICES/DAY 
PAYROLL - 5200 EMPLOYEES PAID WEEKLY 
ACCOUNTS RECEIVABLE - 4000 TRANSACTIONS/DAY 
GENERAL LEDGER 

FINANCIAL REPORTING 

CASH RECEIPTS 

INTER-STORE TRANSFERS 

INVENTORY 

PHARMACY DRUG INFORMATION 
ASSETS/DEPRECIATION 

WORK PROCESSING 


COM (MICROFICHE) 
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OPERATING SCHEDULE/MIX 


3 SHIFTS - 5 DAYS/WEEK 


DAY SHIFT - ALL TERMINAL WORK — 
- TYPICAL 12 - 20 SESSIONS, ONE-TWO JOBS 
NIGHT SHIFT - HEAVY BATCH 3 - 4 JOBS 


GRAVE SHIFT - LIGHT - MODERATE BATCH - “CLEAN-UP” 
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SOFTWARE IN USE 
95% COBOL 
5% SPL AND BASIC 
MOST DATA STRUCTURED WITH LMAGE DATA-BASE SYSTEM 
HEAVY USE OF QUERY LANGUAGE 
- BY PROGRAHHERS FOR TEST/GEBUGS 


- BY USERS FOR REPORTING AND LIMITED UPDATING 


 L6°T8-a 


rt 1 
"1 


TWO MAIN ACCOUNTS: 
PRODUCTH (PRODUCTION) 


-PROGDEV (PROGRAM DEVELOPMENT) 


UCT 


OTHERS : 


SYS 
SUPPORT 
ACCOUNT 1 
PLAYLAND 
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PROGDEV - PROGRAM DEVELOPMENT 


GROUPS 
- BY APPLICATION SYSTEM 


ACP, PAY, EITC. 





ACPS - CONTAINS WORKING SOURCE 
AND OBJECT FILES 


ACP - CONTAINS ACCOUNTS PAYABLE 
TEST DATA 


USERS 
PROGRAMMERS (NO HOME GROUP) 


SECURITY 
ACCOUNT. PASSWORD 


60° TO-a 


SOURCE 


PRODUCTI (PRODUCTION) 


GROUPS 


ALL OBJECT PROGRAMS 
PRODUCT STREAM FILE 
DATA BASE SCHEMA FILES 
(EXECUTE ACCESS TO ALY) 
(QTHER ACCESS TO AL. AM) 
ELL PRODUCTION SOURCE 
(Read ACCESS TO AuY) 
(GTHER ACCESS TO AL. An) 
ALL QUERY XEG@ FILES 


APPLICAT10i4 GROUPS 


psy, SEP, ETC. ALL DATA FILES 
And QUERY PROC.FILES 


USERS 


MGR - USED INFREQUENTLY 


AL - RUNS HOST JOBS 


STANDARD USERS (OUTSIDE EDP DEPT) 


EXCEPTIOWAL USERS (PROGRAWERS) 


NOTE: 


ALL PROGRAMS REG FEC 
APPLICATION GROUPS. ACT 

ONLY BAYA WITKIN TRE Ghour - 
(EXCEPT FOR CERTAI. vara 
BASES ALLGwidG REAG ACCESS 
TO AC. 


er -™ Y-? 
bs a 
LoS wh wwe AS 
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PHYSICAL SECURITY 


DATA SECURITY 


DISASTER CONTINGENCY PLARHING 


AUDIT FUNCTION 


BACKUP 


DONE BY STORE RATHER THAN SYSDUMP 


REASONS : 


STORE MAY BF SELECTIVE 
STORE MAY BE RUN DURING OTHER PROCESSING 


MOST BACKUP DONE BY APPLICATION 


eS) SYS 


USES SET OF GENERATION BACKUP TAPES 

JOLACP; LOZACP cs ica viwns 120ACP = =@— VOLUME ID'S 
ONLY FILES NECESSARY FOR RECOVERY CIN CASE QF 

CRASH) ARE STORED, 

FREQUENCY DEPENDS UPON CHARACTFRISTICS OF APPLICATION 
GROUP 


BACKUP DONE EACH EVENING AT 6:00 P.M, 


FUTURE DATE SYSIUMP 

STORE OF a,PUB.SYS 

STORE OF @,PUB.PRODUCTN, @ XEQ.PRODUCTN, @SOURCE. 
PRODUCTN. 

STORF OF MISC, INTERACTIVE GROUPS 
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CONSOLE OPERATIONS PROGRAM 


READS JOB STREAMS TO TEMP FILE 


~ ALLOWS CONSOLE OPERATOR TO ENTER PROGRAM 


"PARAMETER CARDS” 


STREAMS FROM TEMP FILE 
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SYSTEM MAINTENANCE 


"GOLD" BOOK KEPT 


- SYSTEM PROBLEM LOG 

- MAINTENANCE LOG 

- COPY OF SERVICE CONTRACT (S) 
- CURRENT CONFIGURATION 


"SYSDATA” JOB 


- RUN EACH MONDAY MORNING 
- CONTAINS: 


1) 
2) 
5) 
4) 
5) 
6) 
/) 


FREE 2 LISTING 

REPORT @.@ (+ RESET ACCT.) 
LISTF a.PROGDEV, 2 

LISTF a,PRODUCIN, 2 
MEMLOGAN, LISTING 


DUMMY SYSDUMP 


DATABASE UTILITY LISTING 


- REVIEWED AT DEPARTMENT MEETING 


COLD LOAD DONE EACH FRIDAY EVENING AFTER SYSDUMP 
RELOAD DONE AFTER P.M, 
WEEKLY COMPUTER SCHEDULE PREPARED 
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MISC. RECOMMENDATIONS 
USE “EXCESSIVE” BACKUP AT BEGINNING 
WORK WITH CUSTOMER ENGINEER - LEARN YOUR HARDWARE! 
LEARN SYSTEM UTILITIES 
MAKE FREQUENT CONTACTS WITH OTHER SITES 


SET UP COMMUNICATION METHOD TO USERS 
(IN CASE OF SYSTEM CRASH OR DOWN TIME) 


"MANAGE" SYSTEM 


USE SECURITY FROM BEGINNING 
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DATA PROCESSING SECURITY 


ie PHYSICAL SECURITY 


II, DATA SECURITY 





I, PROTECTION AGAINST DISASTER 


II, EDP OPERATION AFTER DISASTER 
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CURRENT PHYSICAL SECURITY ONGS 


- RESTRICTED ACCESS TO COMPUTER ROOM 


lI, 


II, 


URRENT DATA SECURITY AT LOS 


STANDARD APPLICATION DESIGN CONTROLS 

A, DIVISION OF RESPONSIBILITY 

B. EXTERNAL INPUT AND OUTPUT BALANCING (BY USERS) 
C. USER APPROVAL OF PROGRAM CHANGES 


ACCESS TO DATA RESTRICTED 
A, PASSWORDS 

B, USER CAPABILITIES 

C, EDP DEPT. RESTRICTIONS 


DATA ACCESS “AUDITABLE” 
A, EDP AUDITOR 
B, JOBS MUST "TIE TOGETHER” 
1, JCB REQUEST SHEET 
2, $STDLIST 
3, CONSOLE LOG 
4, SYSTEM LOG 
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1, PROTECTION AGAINST DISASTER 
A, HALON FIRE PREVENTION SYSTEM 


B. QFF SITE BACK-UP OF FILES 


IT, EDP OPERATION AFTER DISASTER 
A. BACK-UP SITES FOR COMPUTER 


B, BACK-UP LOCATION FOR USERS 


HOW SECURITY WAS “INSTALLED” 


A 


PHYSICAL 
- WAS WIDE OPEN, SRADUALLY CLOSED IT OFF 
- PHYSICAL ALTERATIONS 
- INCREASED OPERATIONS PERSONNEL 


- SET UP FORMAL PROGRAM TESTING PROCEDURES 


DATA 
STEPS IN CHRONOLOGICAL ORDER: 


- SET UP “OPEN” PASSWORD SYSTEM 
(EVERYONE KNEW PASSWORDS) 


- STARTED SYSTEM LOGGING 
- JOB CONTROL TIGHTENED 


- SET UP MECHANISM FOR PASSWORD MAINTENANCE 
(BUT KEPT PASSWORDS “OPEN) 


'SIGN-OUT” OF PRODUCTION 


SET UP FORMAL PROGRAMMER "SIGN= 
a FOR TES erING I 1) AUD 


MER ! 0 
DATA NCLUDE I 


l 
t 


SR VORDS TO PROGRAMMERS AND 
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- DEVELOPED CONSOLE OPERATOR PROGRAM WHICH “INSERTS 
CORRECT PASSWORDS INTQ JOB STREAMS - CLOSED OFF 
PASSWORDS TQ OPERATIONS (EXCEPT FOR CONSOLE 
OPERATOR PASSWORD) 


- OBTAINED ENOUGH DISC SPACE TO GIVE PROGRAMMEPS 
SEPARATE “TEST” DATA BASES, 
IN PROGRAM DEVELOPMENT ACCOUNT - DEVELOPED 
UTILITIES TO HELP. 


REMAINING “HOLES” IN SECURITY 


- TEST FILES MAY HOLD CONFIDENTIAL DATA 


- LOS RECORDS DO NOT INDICATE IF A FILE HAS BEEN 
MODIFIED, 


- LACK OF LOG INFORMATION FOR STORE/RESTORE UTILITY 
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COSTS OF COMPUTER SECURITY 


ce 


LO0% 


DEGREE 
OF 
SECURITY 


COST OF SECURITY 
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1) 


2) 


5) 





ISE GRAMUAL PHASES 


INVOLVE EDP AND USER PERSONNEL 
- EXPLAIN “TRADE-OFFS” 


- CHALLENGE PERSONNEL TO DEVELOP GOOD 
COMPROMISES BETWEEN SECURITY REAUTPEMESTS 
AND EFFICIENT OPERATIONS, 


- EXPLAIN THAT LARGE “LOOP-HOLES” WILL 
EXIST DURING IMPLEMENTATION, 


EXPECT VARYING DEGREES OF PERSONNEL RESISTANCE, 
RIDICULE, AND HOSTILITY. THIS SHOULD DECREASE 


- e 


OVER TIME, 
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OBIECTION: “THIS WHOLE SECURITY SET-UP IS A SHAM BECAUSE 
OF (ANY LOOPHOLE)! IT IS NOT PERFECT, S9 IT 
IS WORTHLESS,” 


ANSWER: MOST EDP INSTALLATIONS ARE WIDE OPEN AS FAR 
AS SECURITY. EXPERIENCED COMPUTER CRIMINALS 
ARE LOGICAL PERSONS AND WOULD PREY ON THESE 
SHOPS RATHER THAN ONE WITH EVEN A MODEST 
ATTEMPT AT SECURITY. INEXPERIENCED COMPUTER 
CRIMINALS CAN BE INTIMIDATED BY LESS-THAN 
PERFECT SECURITY PRECAUTIONS. 


OBJECTION: “THESE SECURITY PROVISIONS WILL MAKE MY WORK 
LESS CONVENIENT AND INEFFICIENT.” 


ANSWER TRUE - HOWEVER, OUR COMPANY HAS CHOSEN TQ ACCEPT 


THE COSTS INVOLVED WITH MAKING OUR INSTALLATION 
SECURE. IT’S UP TC US TN MINIMIZE THOSE COSTS. 
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AN EXTENDED OPERATING ENVIRONMENT FOR THE SUPPORT OF 
APPLICATION PROGRAMS 
RICHARD A. BERGQUIST AND STEVEN M. COOPER 
AMERICAN MANAGEMENT SYSTEMS, INC. 


The Brownboard Order and Rollstock Distribution System ( BOARDS ) 
Supports order processing, invoicing, inventory control, and planning 
for the Shipping Container and Containerboard Marketing Division (SCD) 
of the Weyerhaeuser Company. The function of BOARDS is described more 
fully in the paper, "Decision Support System for the Management of 
Containerboard Logistics" by P. DiGiammarino and R. Schwartz. 


American Management Systems, a management consulting and system 
development firm, began work on BOARDS with Weyerhaeuser in September, 
1976. Several subsystems are in production use; the system will be 
fully operational in early 1979. 


BOARDS is written in COBOL, SPL, and FORTRAN, in order to utilize 
the advantages of each language. COBOL was chosen for the majority of 
the system because of its widespread use and report generating abilities. 
SPL was chosen for its efficiency and ability to interface with al] 
aspects of the Operating System. FORTRAN was chosen for number process- 
ing routines such as those that employ linear programming techniques. 


In order to provide an enhanced environment for the programmer without 
the need of becoming familiar with all aspects of the system, sets of 
common routines were developed. These routines also insure consistency 


and compatiability across the System and allow for easy maintenance of 
these technical functions. 


Sets of common routines have been provided that extend the services 
Provided by MPE, KSAM, IMAGE, and DEL. These sets of routines are sum- 
marized in Figure I and are described in more detail in the remainder of 
this paper. 


BATCH JOB SUBMISSION COMMON RGUTINES 


MPE provides a convenient method of introducing batch jobs through the 
use of the STREAM command. However, one problem associated with STREAMing 
jobs is security. To be STREAMed, the User ID must be provided along with 
all appropriate passwords. The problem here is that either the user must 
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FIGURE I 


COMMON ROUTINES 


BATCH JOB SUBMISSION 


FORMS 


VERSION NUMBERS 


DATA BASE ACCESS 
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FUNCTION 


Handles User ID's and passwords. 

Parameter substitution. 

Provides interactive front-end for 
batch job submission. 


Replacement for DEL, enhancements 
include: 


- Protected variable data. 

- Dynamic screens with multiple 
forms and repetitions. 

- Mixed line and page mode trans- 
fer. 


Solves concurrent update problem with- 
out locking data base for entire 
transaction. 

Identifies transactions that failed 
during data base modification 
either because of program failure 
or system failture. 

Extends data base lock across process 
boundries. 


Performs IMAGE calls. 

Performs ‘before’ logging to protect 
against program aborts. 

Performs ‘after' logging to protect 
against file system errors. 

Prevents ‘Deadly Embraces’. 


be prompted for the password, the password must be hardcoded into a program, 
or passwords must be kept within the jobstreams on disc. Prompting the user 
is unacceptable for human engineering reasons, hardcoding does not allow 

for changing of User Id's or passwords, and leaving passwords on disc leaves 
them accessible to anyone who can STREAM the file. Finding none of these 
alternatives acceptable, a common routine to stream batch programs was 
designed. The common routine is passed the name of a template file, job 
parameters, and a parameter string. 


The common routine creates a jobstream from a JOB statement which it 
creates and the statements contained in the template file. The JOB state- 
ment is based on the user running the program and includes all needed pass- 
words. The User ID and passwords are kept in a table in a separate, hidden 
SL procedure. This allows passwords to be changed by Simply modifying an 
SL segment, while allowing only legitimate procedures to access the pass- 
words. As a further security measure, the User ID which is used does not 
have interactive capability -- i.e., it is restricted to batch access. 


The remainder of the jobstream comes from the template file. The 
Streaming procedure substitutes the run parameters which where passed to 
it into the jobstream wherever an ampersand occurs as the first character. 
This allows an interactive program to prompt the user for parameters and 
to then substitute the parameters into the batch system. 


HP2645A COMMON ROUTINES 


The BOARDS terminal network consists of HP2645A terminals with 12K 
memory connected at 2400 baud via multiplexers (one time-division mux and 
one statistical mux), as well as various other. ASCII devices that dial 
into standard BELL-103 type modems. Early in our design phase, we 
determined the needs of programs that would use the HP2645A's in Forms 
Mode, and evaluated the Hewlett Packard product, DEL/30002, in light of 
these requirements. This analysis resulted in two observations: 1) We 
needed certain features not provided by DEL/3000; and 2) DEL/3000 had 
features we did not need or want to pay for in terms of Processing time. 
We therefore developed a set of COBOL-callable, SPL common routines, 
that are used as a total replacement for DEL/3000. Some of the differences 
between DEL/3000 and the BOARDS routines are described below. 


A DEL form is made up of protected fields, whose contents are fully 
defined when the form is created, and unprotected fields, whose contents 
are alterable by the user and are read back to the computer whenever the 
form is read. In addition to these field types, we have defined variable- 
data protected fields. These fields may be filled by the program at run- 
time, but are protected on the screen so that they are unalterable and are 
not transmitted when the form is read. Three examples where these fields 
Proved useful are: 
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@ The user specifies that (s)he would like to enter an order for 
customer code 'ABC'. The name and address for this customer 
are then retrieved from the data base and displayed on the 
screen in variable-data, protected fields, for visual- 
verification by and information for the terminal user. 


@ Whenever an unprotected field is found to be in error, it is 
set blinking and a two-character error code is written to a 
variable-data, protected field at the beginning of the line 
that contains the field in error. 


@ The second line of every screen in the system is called the 
Message Line. It is an 80-byte variable-data, protected 
field in which the application program can inform the user 
as to the status of the processing and inform the user as to 
what is next expected of him/her. 


DEL/3000 allows only one form to be on the screen at one time. Forms 
may be chained together, but this means that after one form has been dis- 
played and processed, the screen will be cleared and the next form will 
be displayed. The BOARDS form routines allow multiple forms and multiple 
repetitions of forms to be displayed on the screen (and in terminal memory) 
at one time. This feature has given us the capability of having dynamically 
sized screens whose length is determined at run-time. It has also given 
us the ability to produce composite screens where each piece is selected at 
run-time from the form file. Similarly, the same form may be used as part 
of more than one screen. 


The BOARDS common routines allow for the programatic control of the 
memory-lock feature of the HP2645A. All of the form routines function 
correctly whether or not memory-lock is set. 


All screens in BOARDS have a similar first line containing, among 
other things, a one-byte unprotected field, called the Control Field. 
Various values may be entered by the user into this field in order to 
alter the normal flow of a program. Several of these values are process- 
ed by the common routines and the application program is not aware that 
this processing occurred. For instance, 'E' means exit, 'R' means redis- 
play the data in the unprotected fields. In several of these cases, once 
the Control Field is read, there is no need to read the rest of the 
screen. So when the ENTER key is depressed, the computer addresses the 
cursor to the Control Field and triggers a field read. If a value has 
been entered, it is processed and the rest of the screen is not read. 

If a value is not found, the terminal is programatically strapped-for- 
page, and a page read is triggered. This allows us to minimize terminal 
I/0's which can become important since some of our screens contain several 
thousand bytes of unprotected data. 
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Another Control Field value that is automatically handled by the 
common routines is ‘P'. Whenever this value is entered, a hardcopy 
printer listing of the screen is produced. If the terminal is equipped 
with an HP2631/240 character printer, the terminal is instructed to 
copy the contents of terminal memory to the printer. For terminals 
without attached printers, the contents of the screen (unprotected, 
protected, and variable-data, protected fields) are written line-by- 
line into a printer spool file. 


Many program functions must operate in inquiry mode on both HP2645A 
and other, non-screen mode, terminals. We therefore developed common 
routines to allow the same application program to operate on a variety 
of different terminal types for display only functions. When a program 
1s run from a non-HP2645A terminal, the escape-sequences are Stripped out 
and the unprotected, protected, and variable-data fields are combined 
on a line-by-line basis and printed, in character-mode, to the terminal. 


Finally, I/0 error recovery is attempted in the common routines. 
This is especially useful in dealing with the multiplexers, since 
Saturation conditions can arise that would result in lost data. When 
an input error is detected, the read is re-initiated repetitively until 
it is either successful or the maximum retry value is reached. If 
none of the retries succeed, the screen is blanked and the form is re- 
written to the terminal under the assumption that either an output 
error occurred while writing the screen or the terminal user inadvert- 
ently damaged or erased the screen. 


VERSTON NUMBER ROUTINES 





The version number routines serve three purposes. First, they pro- 
tect against concurrent update of a data base without locking the entire 
data base throughout the transaction. Second, they allow detection of 
incomplete transactions caused by system or program failures. Third, 
they extend a data base lock across process boundries. 


Within a data base, a logical data path is formed by data which 
are logically grouped together but which may physically cross data set 
boundries. An example of this is a purchase order contained in a header 
record and line items which reside in a detail data set. The logical 
path in this case would consist of the header record and all of the line 
items. 


If two users were to update the same path concurrently, some changes 
might be lost. Figure II shows how two users concurrently changing a 
path might 'lose' a change. 


D-92.5 


FIGURE I] 


User A 


User A gets purchase 
Order XYZ in order to 
update it 


User A adds two bolts 
to the purchase order 
and updates the data 
base. 


User B 


User B also gets Dur- 
chase order XYZ in 
order to update it. 


User B adds three naiis 
to the purchase order 
and updates the data 
base. However, User B 
is unaware that the pur- 
chase order has changed 
since it was originally 
obtained. 


At this point the purchase order does not reflect the 


changes that User A applied. 


That change was lost when 


User B applied his change using the data base record 
retrieved before User A's change was made. 
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To protect against concurrently updating the same path, one must 
lock the data base when one begins the transaction and unlock it when the 
transaction is completed. If there are many users trying to update 
records in the same data base, this method is unacceptable; one user might 
not finish a transaction in a timely manner and the data base will be 
tied up for an extended period of time. 


The version number routines use a data item (version number) for each 
logical data path. When a transaction begins, the version number is 
saved. When the user has completed all of his or her modifications and 
is ready to update the data base, the data base is locked, the version 
number 1s re-read and compared with the original version number. If the 
version number has not changed, then the path has not been modified and 
the program may continue with the user's modifications. At the end of the 
transaction, the version number is incremented. If the version number 
that was re-read has changed, the user must begin the transaction again 
because the records within the path have changed since the transaction 
began. The use of version numbers allows the data base to be locked only 
when modifications are in progress while still protecting against concurrent 
updates. 


To detect if a transaction was only partially completed, an entry 
is made in a table (called the Integrity Table) whenever a modification 
begins and removed when the transaction completes. The Version Number 
routines add the table entry when the version number is re-read and found 
to be unchanged. The entry is deleted at the end of the transaction when 
the version number is incremented. By examining the Integrity Table while 
the system is quiesced, transactions which were only partially completed 
can be identified. 


Under IMAGE, a data base is locked by a process. If the process that 
has a data base locked is aborted, the data base is unlocked. To extend 
a path lock across process boundries (used for backing out of incomplete 
transactions as described in the next section) the Version Number routines 
examine the Integrity Table whenever a version number is read. If an 
entry is found in the table, then the path is currently locked or a trans- 
action was only partially completed. In either case, the path is inacces- 
sible and modifications are not allowed. 


DATA BASE ACCESS COMMON ROUTINES 


From a programmer's point of view, the data base routines are functional 
equivalents to their IMAGE counterparts. While performing as their IMAGE 
counterparts, the access routines are also performing ‘before' and ‘after' 


logging of all transactions as well as protecting against deadlocks when 
the data bases are locked. 
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Protection against deadlocks was accomplished by requiring that all 
data bases be locked at the same time (i.e., one call). The Data Base 
Access routine then locks the data bases in lexicographical order. 


Two types of logging take place; ‘before' and ‘after’. ‘Before’ logging 
consists of saving a copy of all records associated with the transaction 
before any modifications are done. The 'before' log is essentially a 
Snapshot of the data base before the transaction took place. ‘After' 
logging consists of saving a copy of all records associated with the trans- 
action after modifications are done. The ‘after' log is essentially a 
Snapshot of the data base after the transaction takes place. 


‘BEFORE LOGGING’ 


The ‘before’ log is used to restore the data base to its original state 
Should the transaction process complete abnormally. ‘Before’ logging is 
done to Extra Data Segments to improve performance. 


Since IMAGE requires a call to the GET procedure before a recond can 
be updated or deleted, all GETs are logged as they are performed. If the 
retrieved record is later updated or deleted, we record that information 
in the Extra Data segment. Likewise, all PUTs to the data base are also 
recorded in the EDS. Because the order of modifications is important, 
each individual data base modification is assigned a sequence number which 
is saved along with its buffer. If the transaction completes successfully, 
the 'before' log is purged. If the program does not complete successfully, 
the log remains which allows the data base to be restored to its state 
before the transaction began. 


THE DRIVER PROGRAM AND TRANSACTION BACKOUT 


The operating system, MPE, provides for multiple processes to communi- 
cate via the Job Control Word (JCW) facility. The JCW is set to an error 
value by MPE whenever a program terminates in an error state. A program 
may also set the JCW to a particular value indicating an unsuccessful trans- 
action. By examining the JCW, a father process can tell if a son process 
completed successfully, was aborted by MPE, or terminated due to an error 
condition. This facility is used by a program known as the Driver to 
oversee the operation of all programs within BOARDS. 


All programs within BOARDS are son processes of the Driver. It is 
the Driver's function to prompt the user for the function (s)he wishes 
to perform and then initiate the correct program to handle the user's 
function. The Driver then sleeps, waiting for the program to complete. 
If the program does not complete successfully, the Driver initiates a 
program known as Automatic Backout whose function is to restore the data 
base to its original state. Figure III shows the control and data flow in 
the case that a program aborts. 
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FIGURE IT] 





Driver 


Backout 





Control Flow 


Data Flow 
—_—> 


~The driver initiates a transaction program on Request from user. 


The program through the Data Base Access routines retrieves and updates 
the data base. Logging takes place to extra data segments. 


The program aborts. MPE or the Program sets a JCW to an error value. 


The Automatic Backout program is initiated to restore the data base 
to its initial state. 


Automatic Backout restores the data base. 


Control is returned to the driver and it is ready to process next 
users request. 
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Automatic Backout retrieves the Extra Data segments which contain 
the before record and applies the opposite operation as the aborted 
program applied. Figure IV summarizes the required operations. 

All transactions are done in the reverse order that they were done by 
the aborted program. This is necessary to insure that updates are done 
in the correct order and that IMAGE master/detail constraints are 
Satisfied. 


‘AFTER LOGGING’ 


‘After' logging is used to protect against data base transactions 
beging lost because of some error which makes the data base unusable. 
In such a case, an old version of the data base must be restored. If 
transactions were not logged, then all transactions that were entered 
Since the time of the backup must be re-entered by the user. By logging 
the transactions as they occur to a tape, a program can be run to perform 
the data bases transactions which are recorded on the tape. In this 
manner, users need not re-enter data in order to recover from the loss 
of a data base. 


The Data Base Access routines call upon the Malkin and Pinton 
transaction logging3 system to perform the ‘after' logging. 


CONCLUSION 


Through the use of common routines, the features of MPE and other 
HP-supplied system software have been expanded and utilized in COBOL 
application programs, without requiring that the programmers become 
familiar with MPE or SPL. These common routines serve as an Extended 
Operating Environment for the application programs within BOARDS. 
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FIGURE IV 
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BEACON/GUARDIAN: INSTALLATION MANAGEMENT SOLUTIONS 
IN SEARCH OF ELUSIVE PROBLEMS 


WAYNE E. HOLT 
WHITMAN COLLEGE 


SYNOPSIS 


Solutions in search of problems? It sounds odd but really isn't. 
These two software modules are solutions to a very specific type of 
installation management problem, and frankly would not be useful to 


most shops. 


Guardian is a security module designed to increase the security 
provisions on both data files and program files in an environment 
where multiple users work in the same group and account, yet each 

have varying, overlapping, and often contradictory responsibilities. 
lt is especially designed for the type of site where Users are totally 
responsible for data entry and report generation, both on-line and 


batch, rather than a site where the central DP shop handles everything. 


BEACON (Batch Entry Access CONtrol) is a companion module to Guardian. 
If the site allows Users to stream jobs at will, someone or something 
has to play policeman and handle the traffic according to pre-defined 
rules (or in-flight instructions) in order to prevent the system from 
becoming clogged and dying. BEACON handles all job schedules, both 
regular cyclic and demand-mode jobs; it controls the number of jobs 
allowed to run simultaneously based upon system load and time of day; 
it modifies quantum, tpri, cpri, and dpri based upon time of day; it 
provides the DP Center with a concise monitor of all computer activity 
in a convenient format on any designated terminal; and it provides an 


easy to use method of rescheduling or expediting jobs. 


D-12.1 


These software modules are designed to operate in a User-oriented 
data processing center. The application packages that are used are 
specifically designed to enable a non-sophisticated User to very 
quickly learn to operate the terminals and become productive. Smart 
terminals (2645A's) with softkeys provide the tools needed to allow 
this type of user to request jobs with little or no understanding 

of the events set in motion by the request. Without BEACON/Guardian, 


such a shop would be difficult to manage successfully. 
DATA PROCESSING PHILOSOPHY 


Whitman College is typical of many of the current wave of ''emerging'! 
computer users. It had enjoyed a very modest degree of involvement 
with data processing for many years, primarily for business and 
financial uses. Such involvement called for few resources to be 
expended since the needs were correspondingly few. The times changed 
and it found itself unprepared to compete with those colleges that 
were using modern information technology to pursue a diminishing 


supply of student applicants. 


Because of its size, it would be quite difficult to create and staff 

a large Data Processing Center, complete with both Systems and Operations 
personnel. The only viable alternative was to establish a Center whose 
philosophy was oriented toward total control by the User of the actual 
"data processing'' function. The systems design and programming functions 
were retained by the Center, with the User required to know little more 


than :HELLO and :BYE in order to be fully effective. 


A smart terminal, the HP2645A, is the hardware link that allows the 
User-oriented software to function smoothly. Application programs 
using either DEL or VIEW enable sophisticated screen techniques to 
facilitate data entry by non-DP personnel. These programs download 
the terminal softkeys with run instructions in such a manner that the 


User needs only to press a single key to initiate a job. 
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The actual technique is relatively simple (refer to Figure 1). After 
first loading the softkeys by means of a cassette tape or computer 
program, the User presses the key that best describes the type of 
work needed to be performed. This causes a program to be initiated 
that presents the User with a menu (Figure 2). The User selects the 
job function to be performed by keying an ''X'' in the appropriate box. 
Note that the menu lists items in plain English, using phrases that 
the User understands. The menu program then downloads a softkey 
with the necessary :RUN or :STREAM command, along with generating 

any required :FILE statements. The User then presses that key when 


ready to begin work. 


The drawbacks to implementation of this type of philosophy is that it 
causes problems in two major areas: security and system performance. 
For these reasons, Guardian and BEACON were designed. They are the 


software tools that make this kind of environment manageable. 


THE GUARDIAN SYSTEM 


The MPE file management system provides levels of security that perform 
quite well in most situations, particularly where a central organization 
is responsible for production job set-up and related processing. It 
still functions in a user-controlled environment, but not with the 


same degree of effectiveness. 


Consider, for example, a Registrars Office. This type of office usually 
has a mixture of regular and part-time staff, each with varying degrees 
of responsibility. Even among the regular staff, certain functions 

such as grade adjustments can only be performed by specific individuals 
within the office. When this office is automated in a manner described 
earlier, the traditional approach of adding lockwords can cause more 
security breaches than it prevents. Requiring a User to learn multiple 


Passwords usually tends to promote a casual attitude toward such things. 
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some Users, when faced with such an array of mumbo-jumbo, have 
actually been known to post the passwords on the Terminal itself!! 

A User should only be required to know his/her own unique Log-on, 
and it should NOT be shared with anyone else or known by anyone else 


except, of course, the System Manager. 


The approach taken by Guardian is very simple. The Security File 
contains an entry for every valid User and the corresponding programs 
that he/she is allowed to run. All production software calls Guardian 
to validate each request to run a program. Guardian also checks the 
authorized run time and User terminal number as well, treating any 


violations as potential security breaches. 


Further, all important data files are lockworded. Users do NOT know 
these lockwords; rather, they are known only by Guardian, which 

supplies them when the files are opened. This implies that Users 

have no access to their data except through approved software that 
interfaces with Guardian. Unfortunately, this also provides an obvious 
path for security breaches, since only a single password is needed to 
run any particular program to which a given User has access. On the 
other hand, all approved production software creates standard audit 
trails that can be analyzed for irregularities. Thus, the "most obvious 


path" is also the most dangerous for any potential security violator. 


This software technique, oriented toward the specific User, is coupled 
with normal MPE methods to provide a high level of security for all 
Situations. There are two program modules in the Guardian system. Refer 
to Figure 3 for the interrelationships with the BEACON system. 

Guardian. This module is a called subroutine, executed by any program 
in production mode. it is responsible for 


o Authorizing a specific User to have access to a given 
program, 

o Verifying the time of day of use of the program, 

o Verifying the location of the terminal being used, and 

Oo Opening all required files for the calling program. 


lt returns status flags and file buffers to the calling program upon 


successful termination. 
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Sentinel. This module is a stand alone Program that is used to build 
entries in the Security File. It is used to create and modify the records 
that provide Guardian with the information it uses to verify log-on 
requests by Users. Using prompt-answer techniques, it presents al] 
known programs and jobs to the Manager for yes-no responses in relationship 
to a User's capabilities. tt uses the Activity File in the BEACON system 


as a source for this information. 
THE BEACON SYSTEM 


When Users have the capability of performing almost any task (data entry, 
report generation, file maintenance, etc.) whenever they choose to do so, 
the computer system is not going to perform well. The Computer Center 
could set the system limits down to ensure good response time in a FIFO 
(First In First Out) situation, but overall throughput would suffer at 
the hands of such arbitrary measures. Constant operator intervention 
would be required to manage such a Situation, thus defeating the 


whole purpose. 


BEACON is designed to remedy this situation. Fundamentally, its primary 
purpose is to take a batch job request from a User and run it at the 
appropriate time in an efficient manner. In order to do this, BEACON 
actually performs a wide variety of tasks. These tasks are split between 


various program modules. Please refer to Figure 3. 


Gopher. This module is a called subroutine, executed by any program 
that requests a job to be launched. The calling program passes the name 
of the job to be launched and any associated run time parameters to 
Gopher, which in turn builds a Job Request Record in the Activity File. 
It builds the record based on the contents of a Priority Record permanently 
resident in the Activity File, which includes 


Execution priority on a scale of 1 (high) to 9 (low), 
Literal Description of the Job, 

Normal start time (HH:MM), and 

Oo Average run duration in minutes. 


O00 


The Job Request Record is built as a "one time’! record and will eventually 
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be deleted when launched by BEACON. A Wizard number is assigned to 
each Job Request Record and is returned to the calling program by 


Gopher. 


Wizard. This module is a stand-alone program that should be run by 
the operator or account manager. It is designed to perform a wide 


variety of tasks associated with running the BEACON module. 


lt is the tool that is used to modify the contents of the Job Request 
Records in the Activity File when responding to spot requests by the Users. 
Any key field can be altered -- date, time, or priority of launch. Also, 
hot jobs can be placed in a demand-mode launch priority regardless of the 


System load if the priority is altered to "0". 


One of its most important functions is to build a Job Request Record for 
'nbermanent!' or ''cyclic!' jobs. These records are identical to the 
one-time!’ Job Request Records except that the run interval prevents them 


from being deleted by BEACON after launching. 


Wizard also maintains the Clock Records on the Activity File. These 24 


records control various parameters that affect system performance: 


Default execution priority for batch jobs, 

Maximum execution priority for both batch and sessions, 
Quantum, tpri, cpri, dpri, 

BEACON delay interval, 

Video monitor LDEV number assignment, and 

BEACON status flag. 


Wizard can modify any of these items; BEACON will implement them 


00000 0 


automatically. This allows an unmanned system to ''tune'' itself as 


the workload shifts during the 24-hour day. 


Snoopy. This module is designed to be run by the User as wel]! as 
the operator. It produces a formatted display (on either the terminal 
or the line printer) of all jobs waiting to be launched and their expected 
launch times. Snoopy takes into account the average run times as well 
as the System Job limits from the various Clock records in order to 


create as accurate a forecast as possible. 
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BEACON. The BEACON module itself is actually quite simple and very 
efficient in terms of system resource utilization. It is designed to 
be constantly ''up'' as a streamed job although it is normally in a 
‘'sleep!' mode. tt could be run in an interactive session if there were 
an unused port, but this is not likely. It can be started and stopped 


by Wizard, which also controls the frequency of waking up. 


Upon waking up, BEACON checks the System clock and reads the appropriate 
Clock Record in the Activity File. It then adjusts any system 
parameters that may have been changed since the last time that it was 


awake. 


Next, it reads the Job Request Records on the Activity File ina 
sequential mode and determines if a job is ready to be launched by 
comparing the time fields. If there is a priority ''0'' (demand-mode) 
job in the queue it will be launched immediately. BEACON will continue 
searching the Job Request Records until they are all examined or a 
‘'launch ready'' status is determined for one of them. If no job is 
ready to launch, BEACON wil] Skip on to the next step. Otherwise, 


it checks the system load and determines whether to launch or not. 


lf a job is launched, BEACON will then log the System Job number and the 
exact launch time in the Job Request Record and do a KSAM delete. 

Note that this only ''flags'' the record for deletion and renders it 
Invisible to BEACON. It will also regenerate any ''permanent'' Job 


Request Record with the new launch date/time. 


The next step is optional, depending upon a flag set in the current 

Clock Record. If a valid LDEV has been specified, BEACON will output 
a current system status display, showing important system performance 
data. This display could easily be connected to a large video monitor 


for informational display purposes. 


BEACON then goes to sleep for the period of time specified in the 
current Clock Record. 
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Reporter. This module is used to generate an Activity Summary report 
that analyzes BEACON's performance. It is run prior to the daily 
FCOPY ''cleanup'' of the deleted records on the Activity File. It finds 
the Job Request Records of all launched jobs and compares expected 
launch time with actual launch time and calculates various statistics. 
Such a report is valuable in setting the values in the Clock Records 
in the Activity File. It also matches the Wizard number with the final 


Job number, as an aid in tracking down ''lost'' jobs. 
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The following Reserved Words have been added to ANSI COBOL in the 


1974 standard: 
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The following words are tentatively planned for HP extensions 
to COBOL at a future date. This list is subject to change. 


CO} INTRINSIC 
C02 LABELS 

C03 NOLIST 

C04 SEQ 

C05 SWO 

C06 SW] 
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C08 SW3 

C09 SW4 

C10 SW5 

Cll SW6 

C12 SW7 

CC SW8 
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EBCDIC UN-EXCLUSIVE 
EXCLUSIVE VOL 

EXDATE WHEN-COMPILED 
FREE 
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NEW FEATURES FOR COBOL-80 
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TIPS ON CONVERTING IBM FORTRAN PROGRAMS 
TO THE 
HP 3000 
BY 
GARY ANDERSON AND DEEPAK SINHA 


McMASTER UNIVERSITY 


A. INTRODUCTION 


This paper will be useful to anyone wishing to embark 
on the task of converting IBM FORTRAN software to the HP 
3000 Series II or Series TII computers. It should also be 
helpful to anyone who wishes to consider the general 
question of program portability to the HP 3000. 


The material presented here is based primarily on the 
experience of the authors resulting from the successful 


conversion of the BMDP and SPSS statistical Systems to HP 
3000 Series II. 


The problems encountered during these projects arose 
largely from the following four sources: 


1) Incompatibilities between IBM/FORTRAN and Hp 
3000/FORTRAN. 


2) Architectural features of HP 3000 Series II 


computer which impose certain restrictions on 
programs it can run. 


3) Difference between the EBCDIC and ASCII character 
sets. 


4) Difficulties with some library functions on the 
HP 3000. 


The following sections attempt to. cover the above 
problem areas and our proposed solutions in detail. 
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B. FORTRAN incompatibilities between IBM and_ the HP 
3000 


B.1) Type declaration order: 


The order in which type declarations can be made is 
more restrictive on the HP 3000 than on IBM. All type 
declarations must be made before any DATA statements on 
the HP 3000. Further, the data declarations cannot be 
interspersed with type specifications. For example, 
consider the following FORTRAN code for IBM and its 
equivalent on the HP 3000: 


IBM HP 3000 
SUBROUTINE EX1 SUBROUTINE EX1 
REAL B(3)/1.,2.,3-/,A,D REAL B(3), A,D 
INTEGER*2 I, J/9/,K INTEGER*2 1,J,K 

DATA K/5/,A/4.5/— INTEGER*4 INTI, INT2 


INTEGER*4 INTI, INTe DATA B/1.,2.,3./ 
DATA J/9/, K/5/, A/4H.5/ 


END END 
B.2) REAL and INTEGER specifications: 


IBM FORTRAN allows REAL*8 and REAL #4 type 
specifications. On the HP 3000 REAL*8 must be replaced by 
DOUBLE PRECISION and REAL*4 simply by REAL wherever they 
occur. 


The use of INTEGER*4 and INTEGER*2 specification on 
IBM is compatible with the HP 3000 and needs no change. 


It must be pointed out that the default integer size 
on IBM is 32 bits, i.e. any variable specified as 
INTEGER*4, INTEGER, or any integer constant (e.g. 1,2,99, 
etc.) has a length of 32 bits. On the HP 3000, the default 
integer length is 16 bits. This incompatibility can be 
easily removed, however, by including the $INTEGER#4 
command ahead of the source-code before compilation. 


Consider the following equivalent examples on the two 
machines. 
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IBM HP 3000 


PROGRAM EX2 SINTEGER*4 
REAL*8 A,B PROGRAM EX2 
REAL*4 C,D DOUBLE PRECISION A,B 
INTEGER 1I,X REAL C,D 
INTEGER *4 J,K IN“ EGER I,X 
INTEGER *2 L,M,N INTEGER*4 J,K 
; INTEGER*2 L,M,N 
J=K+10 ; 
: J=K+10 
END : 
END 
SUBROUTINE XYZ SUBROUTINE XYZ 
INTEGER I,J,A INTEGER I,J,A 
END END 
SUBROUTINE ABC 
SUBROUTINE ABC INTEGER X,Y 
INTEGER X,Y ; 
: END 
END 


The lengths of the REAL and DOUBLE PRECISION 
variables on both the machines are 32 bits and 64 bits 
respectively. (Remember, though, that the length of 


DOUBLE PRECISION variables on the HP 3000 CX machine is 48 
bits). 


B.3) Mixed specifications: 


IBM FORTRAN allows double precision and real 
variables to be declared in the same statement by 
appending *2 or *4 to the variable name. The IBM 
convention of appending *(number) to a variable or 


function name is totally unacceptable on HP 3000. 
Consider the following equivalent examples: 
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IBM HP 3000 
REAL FUNCTION EX3*8(N) FUNCTION EX3(N) 
REAL *8 A,B¥4,C DOUBLE PRECISION A,C,EX3 
INTEGER 1,J*2,K¥4 REAL B 

INTEGER*4 1,K 

INTEGER*2 J 
END , 


INTEGER FUNCTION INT#2(I) . 
: END 
; FUNCTION INT(T) 
END INTEGER*2 INT 
END 


B.4) Logical variables: 


There are two kinds of logical variables in IBM 
FORTRAN; One byte logical variables, which are typed using 
the LOGICAL*1 declaration, and 4 byte logical variables, 
which are typed using the LOGICAL declaration. All 


logical variables in HP 3000 FORTRAN have a length of 2 
bytes. 


LOGICAL*1 variables or arrays in IBM programs are 
often used to store character strings only, and logical 
tests are not performed on them. In this case, these 
variables or arrays can simply be typed as CHARACTER*1 on 
HP 3000 and they become exactly equivalent. 


When LOGICAL*1 and LOGICAL variables or arrays are 
being used in the logical context (i.e. logical tests are 
being performed on them and they are set to TRUE or FALSE, 
etc.) then there are clearly two options:- 


a) Declare them as LOGICAL on HP 3000, but with 
caution. What if those variables or arrays are 
equivalenced with some other arrays? Or, what if 
they are a part of some other big array, the 
starting address being passed through a 
subroutine -call? Clearly, the IBM calculations 
for the space required by the array will need 
readjustment in HP 3000 programs. Also, since 
the lengths of IBM LOGICAL, REAL and INTEGER 
words are the same, an array declared as REAL or 
INTEGER in one Subroutine can be declared as 
LOGICAL and interpreted logically in another 
Subroutine and vice-versa. This operation is 
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obviously invalid on the HP 3000 because of the 
length difference of a logical variable. 


b) Declare a LOGICAL*1 variable as CHARACTER*1 and a 
LOGICAL variable as an INTEGER or REAL. All the 
logical tests, initializations and assignment 
statements will then have to be changed. 


Consider the following equivalent examples for 
this case: 


IBM HP 3000 
PROGRAM EX4 PROGRAM EX4 
LOGICAL*1 A,B CHARACTER A,B,CTRUE, CFALSE 
LOGICAL X,Y INTEGER X,Y,ITRUE, IFALSE 


IF (A) G=G+1 DATA CTRUE/%1C/, CFALSE/%0C/ 
IF (X) Y=FALSE DATA TRUE/1/, IFALSE/0/ 


B = FALSE IF (A.EQ. CTRUE) G=G+1 
IF (X. EQ. ITRUE) Y = IFALSE 
B = CFALSE 

END 

END 


Another fact to note is that the bit representation 
for the constant TRUE is different on the two machines: 


IBM HP_3000 


Bit 14 15 
30. 31. 


0 1 Bit O 1 4" my 4) 
O ; Oj...[0 | 1 | (=1) TRUE ies eed dol. =- 
fo oto} Oo} tio) ruse = Feros ote} 


. 


In view of the above facts it 1S not possible to give 
a pat solution for every problem arising out of the use of 
LOGICALs but it is recommended that every situation 
involving these variables should be examined carefully. 


B.5) Hexadecimal constants: 


IBM FORTRAN allows initialization of variables using 
hexadecimal constants (e.g. Z18005024 etc.). They are not 
allowed in HP 3000 FORTRAN and must, therefore, be 
replaced by octal or some other equivalent constant. 


B.6) Branching control in subroutine calls: 


The character "&" in an IBM Subroutine call statement 
is used to control branching on return from the 
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subroutine. It must be replaced by "$" on HP 3000. 
Consider the examples: 


IBM HP 3000 
PROGRAM EX5 PROGRAM EX5 
DATA A/Z12345678/ DATA A/%0221505317R/ 


CALL SUB (A,B, &10) CALL SUB (A,B, $10) 
ioc ste 4 jor = oa 


END END 
B.7) Type incompatibilities: 


IBM FORTRAN allows incompatibility between the types 
of the actual arguments (those provided in a CALL 
statement) and the dummy arguments (those within a 
subroutine). For example, a REAL argument can be passed 
to a subroutine whose corresponding dummy argument is 
INTEGER. The HP 3000 allows such incompatibilities only 
if a $CONTROL CHECK=2 statement has been included ahead of 
the subroutine before compilation. The following 
equivalent examples further clarify this point. 


IBM HP 3000 

PROGRAM EX6 PROGRAM EX6 

REAL A REAL A 

CALL SUB (A) CALL SUB (A) 

END END 

SUBROUTINE SUB (1) $CONTROL CHECK = 2 
INTEGER*4 I SUBROUTINE SUB (TI) 


INTEGER*#4 [I 
END END 
B.8) Array bounds: 
A dynamic array bound must be a dummy argument of the 


subroutine statement in HP 3000 FORTRAN. Two equivalent 
examples are given below and some comments are made: 
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IBM HP 3000 


SUBROUTINE EX7 (A,B) SUBROUTINE EX7 (A,B) 

REAL A(N), B(M), C(L) REAL A(1), B(1), C(1) 
COMMON/ABC/M, N COMMON/ABC/M, N 

READ (5,10) A READ (5,10) (A(I), I=1,N) 
WRITE (6,11) B WRITE (6,11) (B(I), I=1,M) 
ENTRY DUMB (C,L) ENTRY DUMB (C,L) 

END END 

SUBROUTINE XYZ (P,I) SUBROUTINE XYZ (P,I) 

REAL P(I) REAL P(1) 

END END 


It should be noted in the above examples that 
Subroutine XYZ needed no modification because I, the 
dynamic bound of array P, is a dummy argument of 
Subroutine XYZ; but M, N and L were not dummy arguments of 
Subroutine EX7 and hence could not be used (for 
dimensioning A, B, and C. Note that L is a dummy argument 
of entry DUMB but that is not sufficient. The implicit. 
length of the arrays A, B, and C was changed to 1 but this 
required the modification of all the READS, WRITES or any 
other statements uSing the implicit length of the arrays. 


B.9) Basic external functions: 


All the basic external functions in the HP 3000 
FORTRAN, particularly the double precision functions, 
require explicit typing in a program. For example, DSQRT 
must be declared as DOUBLE PRECISION in the HP program, 
but this is not necessary in an IBM program. 


B.10) Scientific subroutine library functions: 


Certain IBM scientific subroutine library routines 
like GAMA, DGAMA, LGAMA and DLGAMA are available on HP 
3000 but under the names GAMMA, DGAMMA, LGAMMA and DLGAMMA 
respectively. (Note the two M's in the Spellings). 


B.11) Length of common blocks: 
IBM FORTRAN allows the length of a labelled (or 


named) common block to vary from one subroutine to 
another. HP 3000 FORTRAN permits this phenomenon only for 
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a Single blank (or unnamed) common block. All the 
labelled common blocks must be of the same length in every 
subprogram or else a segmenter error results. The 
following equivalent examples contain one proposed 
solution. | 


IBM HP 3000 

PROGRAM EX9 PROGRAM EX9 
COMMON/A/A,B,C(10) COMMON/A/A,B,C(10), PAD (90) 
END END 

SUBROUTINE ONE (I1,J,K) | SUBROUTINE ONE (I,J,K) 
COMMON/A/P COMMON/A/P, PAD (101) 

END END 

SUBROUTINE TWO (X) SUBROUTINE TWO (X) 
COMMON/A/A,Y,Z(100) COMMON/A/A,Y,2Z(100) 

END END 


In order to determine the maximum length of a common 
block, the source should be compiled with the $CONTROL 
MAP, CROSSREF ALL option. This enables one to know which 
Surbroutines use a particular common block and what the 
lengths are of the common blocks in those subroutines. 


OF RESTRICTIONS DUE TO HP 3000 SYSTEM ARCHITECTURE 
See nav SAD NE EY SU SOL eM ARCHITECTURE 
C.1) Variables in COMMON or DATA: 


The total number of variables declared in different 
COMMON blocks or DATA statements must not exceed 255 on HP 
3000. The reason for this is that the compiler places the 
address of each such variable or array in the primary DB 
area of the stack and the DB relative addressing is not 
allowed to exceed 255 words by the system. 


The problems imposed by this restriction have proven 
to be extremely difficult, especially in the conversion of 
a big system like SPSS. 


One solution is: 
a) Eliminate a common block by including all or some 


of its variables in the argument list of the 
affected subroutines. 
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b) Eliminate a DATA declaration by initializing its 
variables using assigment statements in the code. 
This process, however, cannot be carried out 
indiscriminately. There is one very important 
consideration to keep in mind when comtemplating 
this change. A DATA variable is like a global 
variable, in other words it retains its value 
throughout the program execution. For example, 
Suppose that a subroutine, when entered once, set 
the value of some variable A; now, when it was 
entered again, if A was not a global variable, 
its value would be indefinite. By being removed 
from a DATA declaration, the status of a variable 
is changed from global to local. Hence, before 
removing a variable from a DATA statement one 
needs to understand the program logic to 
ascertain whether or not this particular variable 
needs to be global. Only those DATA variables, 
not required to be global, may be initialized by 
assignment statements. 


It is the experience of the authors that this process 
can be tedious, time consuming and has the potential for 
introducing an unending string of "bugs" in a program. 


A new capability likely to be available in the future 
version of the FORTRAN compiler may remove this 
restriction, at the expense of execution time, by 
providing the $MORECOM compiler option. 


C.2) Subroutine arguments: 


The maximum number of arguments in a= single 
Subroutine on HP 3000 cannot exceed 54. The reason for 
this limitation is that whenever a subroutine or function 
is called, the address or values of the actual arguments 
and a four word stack marker’ are placed on the stack and 
Q-minus addresses are assigned to them. Q-minus 
addressing cannot exceed 63 words, hence the limit. 


C.3) Local variables: 


On an IBM machine, the local variables within a 
Subprogram retain their values between calls to this 
Subprogram, unless this Subprogram happens to be overlaid 
with another’ subprogram. In particular, programs with 
only one overlay always retain the values for local 
variables throughout a run of the program. This is never 
true on HP 3000 because the system stack is dynamically 
increased when a subroutine is called and decreased when 
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the subroutine is exited. Consequently, all the local 
variables are lost with the updating of Q register. 


The only solution to this problem is to understand 
the program logic so as to determine which variables need 
to be removed from the list of local variables and be made 
global. Once identified, these variables must be placed 
in a common block. 


C.4) Addressing: 


IBM and many other machines use a_ byte oriented 
addressing scheme. This means that given an address, the 
System can identify the proper byte in memory which may or 
may not be at aeword boundary. HP 3000 system uses 
related .but different addressing schemes’ for words and 
bytes. The right most bit of a byte address indicates 
whether it is the left or the right byte of the word whose 
address is given by the remaining bits. The implication 
is that given an address, the system also has to know 
whether it is a word or byte address. 


The HP 3000 FORTRAN compiler generates word addresses 
for REAL, INTEGER, DOUBLE PRECISION or LOGICAL variables 
but byte addresses for CHARACTER type variables’ or 
strings. For this reason, it is not possible in HP 3000 
FORTRAN, as opposed to IBM FORTRAN, to pass a character 
string or variable in a subroutine CALL statement when the 
corresponding dummy argument is not of a CHARACTER type. 
The converse also holds true. 


One can use equivalencing of variables to solve this 
problem but a more innovative solution, and one that has 
been used in the SPSS and BMDP-77 conversion projects, is 
to use an SPL program to modify the address in question 
and pass this modified address to the called subroutine. 
The following examples should clarify this concept. 
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TBM HP 3000 


PROGRAM EX10 PROGRAM EX10 

REAL A REAL A 

CALL SUB1 (A) CALL SUBIM(A) 

END END 

SUBROUTINE SUB1 (B) SUBROUTINE SUB1(B) 

LOGICAL*1 B(1) CHARACTER B(1) 

END END 
$CONTROL SUBPROGRAM 
BEGIN 


PROCEDURE SUB1(B); 

BYTE ARRAY B; 

OPTION EXTERNAL; 
PROCEDURE SUBIM(B); 

REAL B; 

BEGIN TOS:= @ B & LSL(1); 
SUB1(*); END; 

END. 


Conversion of a word address to a byte address is 
Straight forward but while converting a byte address to a 
word address one must note that if the byte address is not 
at a word boundary then there is no way it can be 
converted to a word address. However, such a situation 
rarely arises. 


C.5) Code segmentation: 


AS opposed to specifying overlays on an IBM System, 
one needs to define code segments on HP 3000. All the 
code must belong to some code segment. There is an. 
allowed maximum size and an allowed maximum number of code 


segments which are fixed at the time of system 
configuration. 


The implication is that there is a limit to how large 
a program that runs on HP 3000 can be and how large a 
Subprogram can be. If a subroutine, or any other 
Subprogram cannot fit within one code segment then it must 
be split up into two or more subprograms. The task of 
Splitting subroutines is a difficult one and generally 
introduces "bugs" in the program. We have found that a 
code segment size of 8K bytes will generally handle the 
largest of FORTRAN subroutines or programs. 
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C.6) Data stack limitation: 


The entire data stack used by a HP 3000 program must 
not exceed 32,767 words. This restricts the size of 
Scratch areas and other arrays in a program. In order to 
use the stack judiciously, one must have as few global 
variables and arrays as possible so that there is more 
Space available for local variables. There is a permanent 
allocation of stack for the global variables but a dynamic 
allocation for the local variables. This 1S one reason 


why a lot of DATA declarations in SPSS had to be 
eliminated. 


It may be noted that in order’ to use the maximum 
Stack size, the program should be prepped or run with 
STACK parameter set to 819 and MAXDATA parameter set to 
32767. 


C.7) Real word configuration: 


The exponent and fraction parts of a real word on the 
two machines are as shown here: 


HP 3000 PLPEREPAL EEE) 
rca sae 
S sn exponent Lroction 


ATT = 


In addition, on tue HP 3000, a 1 is always Implied to 


left of the binary point. Real 0 is the only exception to 
this rule. 








It should be obvious that the range of magnitude for 
the real numbers is more on HP but’ the precision is 
Smaller by one bit compared to IBM. 


C.8) Distinction between BLANK and ZERO: 


The IBM formatter upon detecting blanks in a field 
being read using Fw.d specification, turns the left most 
bit of the real word ON (the remaining bits are 0). This 
real word, while being distinct from +0, has an arithmetic 
value equal to 0. The HP 3000 formatter returns a +0 upon 
detecting blanks under the same conditions. Hence there is 
no way of distinguishing between blanks and zeroes while 
reading a field under Fw.d specification. 
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It may be noted that even if one, somehow, manages to 
turn the left most bit ON, the value of the real word will 
not be -0, it will be -.863617 E-77 because of the biased 
exponent and an implied 1 to the left of the binary point. 


D. INCOMPATIBILITIES DUE TO EBCDIC & ASCII CHARACTER 
SETS 


D.1) Alphabetic and numeric tests: 


Very often, in order to determine whether a character 
1s alphabetic or numeric, its numerical value is tested. 
AS one would expect, the numerical values for the EBCDIC 
Character set used by IBM are different from those for the 
ASCII character set used by the HP 3000. The following 
table compares some of the values aSSuming that the 
character in question occupies the right most byte of the 





word. 
CE EBCDIC.... |. ASCTT| 
193 = 233 65 - 90 





0 - 9 240 - 249 48 - 57 
32 






The following equivalent examples include one 
instance of such a test. 


IBM HP 3000 
PROGRAM EX11 PROGRAM EX11 
LOGICAL *1 A(a) CHARACTER A(4) 
INTEGER *4 1 INTEGER *4 1 
EQUIVALENCE (I,A) EQUIVALENCE (I,A) 
DATA I/4Hbbb9/ DATA I/4Hbbb9/ 

IF (I1.GE.240 AND IF (1.GE.48 AND 
I.LE.249) GO TO 10 I.LE.57) GO TO 10 

10 INUM = I - 240 10 INUM = I - 4g 

END END 


D.2) Alphabetic sorting: 


Imagine areal or double precision array which needs 
to be sorted in alphabetic order. One method is to 


compare the numerical values of the words and take the 
appropriate action. The left most bit of every EBCDIC 
alphabet or numeral is 1, which in the position of a sign 
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bit makes a number negative. The implication is that the 
value of A is greater than the value of B etc. In ASCII 
character set the left most bit of alphabets and numerals 
is 0O which implies that the numerical value of A is less 
than the numerical value of B etc. Hence, the logic of 
all the tests, performed on EBCDIC character strings to 
sort them in an ascending alphabetical order, will have to 
be reversed to sort ASCII character strings in the same 
order. 


E. PROBLEMS WITH HP 3000 SCIENTIFIC SUBROUTINE LIBRARY 
FUNCTIONS 


E.1) DFLOAT: 


This double precision function, on HP 3000, always 
returns a zero regardless of the input. One has to supply 
his or her own DFLOAT function in the program or replace 
DFLOAT(I) by DBLE(FLOAT(I)) type of conversion. 


E.2) LGAMMA: 


This function on HP 3000 aborts when the input is 
Smaller than 7.0. One way to get around this problem is 
to use DLGAMMA which seems to work correctly. 


E.3) Initialization of DOUBLE PRECISION words: 


As the HP 3000 FORTRAN manual suggests, it is not 
possible to initialize a double precision word using 
2"ABCDEFGH"D form. Only the first four characters of the 
String are stored. To get around this problem, one has to 


equivalence the double precision word with real words and 
initialize the real words. 


F CONCLUSION 


Although there are many potential areas of 
incompatibilities between IBM FORTRAN code and that on the 
HP 3000, the potential gains from converted software can 
make the effort well worthwhile. There is a great wealth 
of well written and thoroughly debugged software on IBM 
Systems which will run on the HP 3000 once converted. We 
feel that our effort in converting the SPSS and BMDP-77 
Systems, for example, has been an extremely successful 
one. In fact, we are actively pursuing other FORTRAN 
software packages to convert to the HP 3000 as we have 
found that programs compiled from FORTRAN seem to run 
surprisingly efficiently on the HP 3000 computer system. 


E-8.14 


G. ACKNOWLEDGMENTS 


The authors would like to acknowledge the 
contributions of the members of the software group in the 
Computation Services Unit at McMaster and their assistance 
in finding solutions to the conversion problems described 
in this document. Their general support role in making 
these two rather massive conversion projects successful is 
also greatfully acknowledged. Dr. Khursheed Ahmed's 
assistance in the initial assessment of the projects and 
in the conversion design as well as his Ongoing support 
have been most helpful. Mr. Kim Clark has proved to be a 
rich Source of useful suggestions. Maria Wong has 
provided valuable input all through the projects with user 


interfacing problems and with testing and improving the 
final products. 


Lastly, the authors would like to acknowledge the 
Support of Hewlett Packard, SPSS Inc. and the personnel of 
the Health Sciences Computing Facility at UCLA. 


H. REFERENCES 


1) Anderson, G. D., "Converting IBM 360 and 370 
FORTRAN to the HP 3000 Series II" Journal on the 
HP 3000 Users Group, Vol 1, #3, Sept./Oct. 1977. 


2) Anderson, G. D., "BMDP Program Conversion to the 
Hewlett Packard System 3000 Computer" Internal 
document available from Department of Cw. Es. Bay 
McMaster University, Hamilton, Ontario, L8S 4J9. 


3) HP 3000 Series II Computer System, FORTRAN 
Reference Manual. 


4) IBM System/360 and System/370 FORTRAN IV Language 
Reference Manual. 


E-8.15 


WRITING SPL ROUTINES WHICH 
ARE CALLABLE FROM BASIC 


BY 


WARREN KUEHNER 
SYSTEMS ENGINEERING SUPERVISOR 


HEWLETT-PACKARD 


NEELY SALES REGION 
ENGLEWOOD, CO. 


E-99.1 


This paper discusses programming techniques involved in 

the creation of SPL routines to be called from BASIC. It 
specifically covers both trivial and more complex programming 
examples, and consideration, for putting these routines 

into operation with BASIC programs. This paper assumes a 


good knowledge of both SPL and BASIC. 


HOW BASIC CALLS A SUBROUTINE: 

The key to understanding the possibilities for BASIC callable 
SPL routines is to understand what additional information (other 
than that which is normally passed) BASIC provides with a call. 
In addition to the passed parameters and the stack marker, 

BASIC places two other pieces of information on the stack 

ahead of the passed parameters. One is the number of parameters 
passed. The other(s) are a code word for each passed parameter 
indicating what data type it is and whether it is a Simple 
variable or an array. (Refer to Appendix F of the BASIC/ 3000 
manual for information on the codes and the passed parameters). 
This information can be used by the SPL routine to verify 

the correctness of passed parameters. Another use is to allow 
the passage of a variable number of parameters to the SPL 


routine. 


When BASIC calls an external routine, the stack is as illustrated 


on the following page. 
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Old Stack Marker 
oLpas 
Code Words 
Tewamewrs | 
0-4 
stack 
marker 
Q 


BASIC first calls a routine (which generates a stack marker) 
which places an integer indicating the number of parameters, 
the parameter codes, and the addresses of the passed parameters 
(in that order) on the top of the stack, and then calls the 


desired external routine. 


THE TRIVIAL PROGRAMMING CASE: 

Given the foregoing background information, it should be 
obvious that in the trivial case, SPL routines can be written 
in the normal way and called from BASIC. For "quick and 
dirties" this could be adequate. It should be noted that 
BASIC does no passed parameter checking of any kind and 


this approach is potentially risky. 
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THE MORE COMPLEX CASE: 

It has been pointed out that the additional information on 
the stack can be useful for at least two reasons; parameter 
checking and variable parameter passing. The following 


program example illustrates how to get at this information: 


INTEGER DELTAQ = Q - @; (( THIS VARIABLE, WHICH IS LOCATED AT 
Q (WHICH CONTAINS THE DISTANCE BACK 
TO THE LAST LOCATION OF Q) ALLOWS 


US TO FIND OUR WAY AROUND) ) 


INTEGER POINTER NUMPARM;(( POINTERS TO THE VARIABLES CON- 
CODES , TAINING THE NUMBER OF PARAMETERS , 
PLIST; THE PARAMETER CODES, AND THE BASE 


OF THE PARAMETER ADDRESSES ) ) 


@NUMPARMS: = (@DELTAQ + 1) - DELTAQ; (( NUMPARMS MUST POINT 
TO THE ADDRESS OF ''Q" 
PLUS 1 LESS THE VALUE 


OF DELTAQ) ) 


@CODES: 


(@DELTAQ + 2) - DELTAQ: (( SEE ABOVE) ) 


@PLIST: @CODES + (NUMPARMS + 2)/3; (( THIS CALCULATION WILL 
CAUSE PLIST TO POINT 
TO THE ADDRESS THE 


FIRST PASSED PARAMETER) ) 
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By indexing through PLIST and equating its contents to other 
pointers, one can locate any of the passed parameters. For 
example, to locate the third passed parameter which is a string 
(byte array) the following is necessary: 

BYTE POINTER STRING; 

@ STRING: = PLIST (2) 
Obviously, the problem of checking parameters can be solved, 


being able to get at the number of parameters and their types. 


The variable parameter passing problem can also be solved with 


this information. 


The idea of variable parameter passing can be very useful. 
Good examples are the Basic callable Image routines. DBGET 
can, for example, be passed a variable number of strings to 
receive the buffer of data from the data base. This gets 
around the Vimieation on string length as well as allows the 
placement of logical pieces of the data in the data base in 


strings dimensioned to contain them. 


It should also be noted that information about the length 
of a string variable (and also about array dimensions) is 
available to the SPL programmer, and that this too can be 


quite useful. 


For example, if STRING is a string variable (byte array), 
then STRING (-1) contains its length as dimensioned in the 
BASIC program. (Refer again to Appendix F of the BASIC/3000 


manual for more information. ) 
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NOW I WROTE IT---HOW CAN I MAKE IT RUN? 

If one is running his BASIC programs from the interpreter, 
the external routine called must be located in an SL file, 
either in his group, in his account's PUB group, or in the 
system SL. The interpreter automatically searches all three. 
To place the routine in the SL, one must use the SEGMENTER, 
and the procedure is as follows: 

SPL MYPROG, MYUSL 


6 CONTROL SEGMENT = MYSEG 


END. 
SEGMENTER 
- USL MYUSL 
- SL SL ((BUILD AN SL IF YOU DON'T HAVE ONE)) 
- ADDSL MYSEG 
- EXIT 


----NOW RUN! 


To use the routine from a compiled program, the steps are 
the same as for a compiled program in any language, that 
is, the routine may be either: 
- Compiled into the same USL file as the BASIC program 
and then that USL PREPED. 
- Put into an RL file (with the SEGMENTER) against 
which the USL can be PREPED 


>: PREP MYUSL, MYPROG; RL = MYRL 
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- Called from an SL. Remember if the SL is in your group 
to use the appropriate LIB = parameter, that is: 


>: RUN MYPROG; LIB = G. 


The purpose of this paper was to present the tools to write 
BASIC callable SPL routines. I would enjoy your comments, 


criticisms, or to hear what you've been able to do with these 


ideas. 
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AN EXAMPLE OF SPECIAL@“PURPUSF 
LANGUAGE DESICN AND IMPLEMENTALLON 


Matthew J. Balander 
The K & B Computer Company 


ABSTRACT: Special-purpose programming languages are often an 
excellent method Ot reducing costs and improving 
productivity. This paper discusses some of tne factors 
influencing the decision to develop and employ a 
special-purpose language, and presents an example of such a 
lanquage. The language presented, DEC/3000, provides 
powerful data-entry capabilities for programmers producing 
applications in host languages. In tests, the use of this 
special=-purpoose language nas indeed reduced costs’ and 
imoroved programmer productivity. 


1. wWny another language? 


Despite the (quite proper) effort to develop good general 
purpose programming languages in the discipline of computer 
science, there are nonetheless still problems’ for which 
specialepurpose languages should be emphasized regardless of 
considerations of universal applicability or voortability. 
Factors which motivate the effort to design and implement 
such languages, to adopt them for use in applications, and to 
educate programmers in their use include cost effectiveness, 
programmer productivity, program reliability, and 
maintainability of the final product. 


Languages should not of course be implemented to meet every 
whim of each programmer. Problem areas for which languages 
Should be provided must be very carefully defined, if the 
language to be provided is to tulfill its goals of lowered 
software production costs and improved programmer 
productivity. An appropriate problem area may be identified 
as foOllows: 


o It must be possible to clearly define the problem 
area. It is, for example, an inadequate isolation ot 
the problem area to state, "A language is needed to 
help with data entry tasks." The problem area must be 
carefully, Clearly, and fully specified. Tne 
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construction of a "language" is under consideration. 
It is critical to understand fully exactly wnat the 
proposed language is supposed to be able to "talk" 
about. 


o The programming of solutions in the probdlem area, 
using available languages, is tedious, conplex, and 
error*prone. Existing languages, in other words, are 
not well suited to the expression ot solutions to 
tasks in the problem area. The degree of aifficulty 
witn which solutions are provided in existing 
languages is a measure of the cost of solvina pronlems 
in those languages, and, in qeneral, an indication of 
the future costs ot reliability and maintainahility of 
the software. (Tne cost of the proposed language may 
thus pe measured relative to the cost of existing 
languages by noting the reduction in complexity of 
sOlutions provided in the special-purpose lanquaye,.) 


o An area is a candidate for a special-purpose language 
if programs are frequently produced to meet needs in 
the area, or such programs are heavily used. Tne 
eftort involved in designing and implementing a 
special-purpose language cannot ve justifiea if the 
language produced will rarely be used, 


Tne decision to proauce a special-opurnose language is thus 
largely governed by economic factors. If a special language 
will reduce costs sufficiently, it will provide a 
costeettective means Of providing solutions to data 
processing problems. lIanguages achieve cost reductions in 
the software development cycle in several ways. Some of the 
more straight-forward are as follows: 


Oo BY increasing the power of the language peing used py 
programmers (defining "power" loosely as the amount of 
work done for the programmer by a line of code) the 
size of programs, measured in lines of code, is 
reduced. Given a fixed cost per line of finished code 
regardless of language, there is a direct savings in 
program development cost in using a powerfu] 
specialepurpose language. 


O A welledesigned language is easy to use. Its idioms 
and methods of expression are "natural" for expressing 
solutions to the cateqory of problems for which it was 
designed. This redauces the complexity of solutions to 
problems. Complexity of a orogram varies inversely 
with reliability of the program, The less complex a 
program is, the more reliable it is. Greater 
reliilability means lower costs for software 
development. As a result of reduced complexity, 
testing is simplified, and debugging is both easier 
and less time consuming. 
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Oo Ihe increased power and reduced complexity of a 
special-purpose lanauage serve to reduce’ software 
maintenance costs. Adjustments and moditications oft 
prodqrams will require less programmer time, affect 
fewer lines ot code, and may with greater contidence 
be undertaken by proaranmmers who did not originally 
write the software peing modified. Program 
modification in addition enjoys tne same benefits from 
increasea power and reduced complexity that are 
exnerlenced during original software development. 


From all fnese remarks it is plain that the use of 
soecial-purpose programming languages can be very 
beneficial. It is also plain that tne benefits received 
aqependg heavily on the language design and imolementation. 


2. HOw is a special-purpose language designed? 


Once a problem area has peen defined for whicn a 
special-purpose language is beinq considered, the language 
must be designed. The design of a language is an art, not a 
tecnnology. It will always remain so, since language is an 
intensely human activitv, and is fundamentally alien to 
mechanical processing. It is far beyond the scope of this 
paper to discuss lanuuaage design in detail, but some central 
considerations should be mentioned, 


The language designer must Know the problem area. This 
involves not just a passing acquaintance, but an intimate 
familiarity. Such knowledge usually is a result only of much 
work in the field. Ine language desiaqner must be tamiliar 
with the problems of the problem area, and with the sorts of 
solutions with which they are best met. He must be aware of 
the limitations of available languages when applied to 
proplems in the field, and nave some experience with trying 
to “inake do" witn these languages. 


tne language designed must be powerful, It it is not 
sufficiently powerful, many of the nenefits of implementing 
the language will be lost. Language constructs and idioms 
must be provided which allow the programmer to express as 
concisely and unambiguously as possible his intentions. 
Hrief constructs are preferred to wordy ones, and one line 
of code to two or more. On the other hand, the APL-ish, 
mystical, "“does-it-all" one-liner type of language is most 
certainly not desirable. Readability should always be 
maintained, 


when providing power, it is necessary to be cautious that 
flexibility is not unduly limited. Regardless of the power 
of the language, it will not be used by programmers if they 
are unable to express solutions to all relevant problems 
with it. In zeal for making the programmer’s life easier, by 
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"doing all the work tor him," care must be taken not to make 
it aitficult or impossible for him to solve atypical or 
unanticipated problems using the languaqe. 


Ihe lanquage designed must be "natural." that is, it must 
express programs in much tne same way that the programmer 
thinks, or should think, about them. A judicious compromise 
petween machine efficiency and programmer comfort must poe 
touna,. It is here that tne art of the language agesigner 
will be most needed. 


3. how is the lanaquage to be implemented? 


while language design is the most critical phase of the 
production of a lanquage, implementation is by no means 1eSS 
important. A good, reliable, easy*to-use implementation of 
the language must be provided to programmers. lt must take 
into account their needs and work. An imolementation wnich 
is difticult to use, or which is unpredictable or unreliable 
in its operation, will not be used. The documentation, not 
only of the language, but also of the implementation of the 
language, must be comprehensive, clear and concise. It 1s 
an integral part of the implementation as a whole. 


Tnere are three very viable options for implementation of a 
language: a pre-processor, an interpreter, and a compiler. 
The simplest of these is to implement a pre-processor tor 
some existing language. The special-purpose language then 
takes the form of statements embedded in a program text 
ultimately intended for some existing nrocessor. Tnis text 
is first fed throvahn the pre-processor, which converts tne 
specialepurpose language statements into source statements 
of the language in which the special-purpose statements are 
embedded, and outouts a program text which may be submitted 
to the existing processor. Such a concent is familiar and 
has been used successfully in such systems as RATFOR, a 
pre-processor for FORTRAN programs providing while, 
doewuntil, and similar constructs. 


If all existing lanquages are so unsuited to tne problem 
area that it is not wise to preeprocess special-purpose 
language Statements into one of them, then the 
implementation must provide all the functions of a 
source-lanquage processor. One way in wnich tnis is often 
accomplished is to implement an interpreter for tne 
language. Interpreters have many familiar advantages, and 
are not as difficult to implement as most other options. In 
addition, the technology of interpreters is well documented 
in the literature, and good advice may be found there to 
assist in writing the interpreter itself. 


Although interpreters have many well Known advantages, they 
also nave many well know disadvantages. They are slow, 
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often bulky, and usually nave no convenient mecnanism for 
accessing the full capabilities of the operating system and 
allied subsystems in which they are used. It tne 
disadvantages of an interpreter weiyh heavily in a 
particular situation against its use, the next alternative 
is to implement a full compiler. Implementina a compiler is 
undoubtedly the most ditficult and time-consuming ot the 
options, but possesses most otf the advantages of the other 
options, as well as some unique to the use of a compiler. A 
well written compiler provides access to all system 
capabilities (assuming the lanquage design has been done 
well enough to allow the language itself to express access 
to these capabilities). It provides much more efficiency 
than an interpreter, and is more congenial to a variety of 
environments, both batch and interactive, 


The type of implementation to be used depends on the nature 
of the problem area itself, on the time and resources 
available for implementation, and the ways’ in wnich it is 
desired to use the finished processor. Pre-processors are 
the easiest to write, port, and maintain, compilers the most 
difficult, and interpreters are somewhere in petween. In 
some cases hybrid implementations are most appropriate. 
Here the craftsmanship of the programmer implementing the 
language is of great importance, Tf the available 
programmers are not skilled in compiler writing, or have no 
experience in compiler writing, it may be unwise to ask them 
to implement a production compiler. On the other hand, the 
concepts and engineering of preeprocessors are not of great 
difficulty, and most programmers with some experience in 
text processing can implement preeprocessors in a reasonable 
amount of time. Interpreters, as compilers, require some 
special skills, and should not be undertaken py a Statf 
without some prior experience in the area. 


4. Can you give me an example? 


The author has written a number of data entry programs, each 
of which was a portion of a larger data processing system. 
In each case, interactive terminals witn forms and wnlock 
mode Capabilities were used. These programs were 
implemented in FORTRAN, COBOL, and SPL, as appropriate to 
the data processing system for which the data entry proaqram 
was being written. Tne specifications for the programs 
indicated that the forms/block mode capabilities of tne 
terminals were to be used whenever possible to assist 
terminal operators in entering data correctly. 


In preparing to write these programs, it was necessary to 
learn a great deal about the terminals to ne used (HP264xX 
terminals were used for these particular pvprojects). Not 
only was it incumbent on the programmer to be fully 


E-190. 5 


conversant with the application, but also to be an expert on 
the terminals themselves. Programming terminals sucn as 
HP2604X terminals is in fact a form of low-level machine 
programming, and as such is quite prone to errors. No 
special software tools were available to assist in managing 
the terminals; all functions had to be explicitly provided 
by the applications programs. 


In one case, eighty lines of SPL code were needed for the 
"DEFINES" used to code the declaration of a single form ina 
fashion which was at least partially readable. In one 
FORTRAN program approximately two hundred lines of code were 
devoted exclusively to terminal management. In general, it 
was found that approximately one third of each of these 
programs were devoted to terminal management, with 
approximately one hundred lines per program devoted to 
defining and managing forms for display on the terminals. 


Not only were terminal and form management lengthy, they 
were also difficult to code. The escape sequences used with 
HP2604X terminals are meaningless in and of themselves. They 
are simply details which must be coded precisely in order 
for tne terminal to behave as desired. Programmers who are 
not the original author of these programs will find it 
difficult to modify the forms involved when data needs 
change; tne original author himself will find changes 
difficult. 


A search was of course made for alternative methods of 
coping with the problem of managing these types of terminals 
during data entry. The only software available at the time 
was Hewlett Packard’s DEL/3000, It was evaluated, and 
rejected for several reasons. First, it did not relieve tne 
programmer of the necessity of being an expert on the 
terminals. To declare a form in DEL/3000 the programmer 
must actually produce the form from the keyboard of an 
HP264X terminal. He must still be familiar with all 
appropriate escape sequences. Second, DEL/3000 had to be 
used from an HP264X terminal. Not all terminals used for 
program development at the installation where this work was 
being accomplished were HP terminals. Also, because of this 
restriction, work on the forms and terminal management had 
to be done oneline instead of in (less expensive) batch. 
Third, DEL/3000 held out no hope of ever supporting any but 
Hewlett Packard terminals. Other forms/block mode 
capability terminals are available, and it is not wise to 
write one’s software so that one is locked into a single 
vendor. Other objections, such as the "unwaesthetical" 
nature of DEL/3000, were raised, but could not be related to 
clearly definable, measurable problems. 


The rejection of DEL/3000 was the rejection of the only 


available software tool for forms/block mode data entry with 
sufficient power to be considered. The remainder of this 
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paper discusses the alternatives which we considered, and 
aescrives the solution we reached, We turned to consider 
what sort of tools we should implement ourselves. (In the 
meanwhile, the writing of data entry programs was undertaken 
using the various available languages, since it was not 
feasible to delay their production till more powerful tools 
were available.) What ever we came up with had to meet the 
tollowing goals: 


o The tool produced must perform virtually all terminal 
and form management during data entry. 


Oo fhe tool must relieve the applications programmer of 
the necessity of understanding the programming of the 
terminal being used. The programmer should never need 
to Know what escape sequences are used to perform 
terminal functions. 


o It must not be necessary to have one of the data entry 
terminals available tor the orogrammer’s use during 
coding of the application. 


o The tool must provide for adequate documentation of 


fOrms. It is not considered sufficient for forms to 
pe simply entered at the keypoard; there must be a 
permanent, Off-line record of eacn form clearly 


showing all protected/unprotected tields, display 
enhancements, and so on. 


o The tool must allow for future use of non-HP terminals 
with a minimal conversion effort. It is acceptable to 
need to rework the tool itself, but minimal changes 
should be necessary in applications programs. 


o fhe tool must dovetail with existing applications, and 
existing application languages, so that a conversion 
process may be undertaken, and so that programmers and 
analysts are not restricted in their choice of 
language, 


Clearly a new programming language was called for. A 
carefully designed language, together with a comprehensive 
run-time support library, is capable of meeting all these 
goals. Implementation method was decided immediately. A 
pre=processor is not feasible because of the last goal. The 
new language must dovetail with a number of existing 
languages (at the least witn COBOL, SPL, and FORTRAN), but 
pre-processors are Oriented to a single application 
language, The ditficulty of implementing several 
pre=processors, and the maintenance nightmares arising from 
having three or more programs that do the “same" thing, 
caused the firm rejection of a pre-processor. An 
interpreter was rejected for the same reasons’ that tne 
pre-processor was rejected. (It is possible to construct an 
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interpreter which is invoked by a program when needed, but 
sucn constructs are difficult on the HP3000 under MPE. 
Also, the use of such a system is burdensome on the 
programmer, andis not conceptually straight-forward.) we 
settled on implementing a compiler. 


Since it is desirable to use the data entry tool with a 
variety of applications coded in a variety of languages, a 
"host language" concept was adopted. That is, program units 
coded in the new, special-purpose language would be used 
together with program units coded in some “host language." 
It was agreed that only the following restrictions should be 
placed on the choice of host language: the nost must be 
able to call external program units, and to pass simple 
integer and integer array parameters by reference to these 
external program units. In this way, the special-purpose 
language program units would be accessable from at least 
COBOL, BASIC, SPL, and FORTRAN. Since no other potential 
hosts were in use at the time, tnis was considered to be 
sufficient. 


The name "DEC" was adopted for the compiler and associated 
language. It is an acronym for “Data Entry Compiler." Since 
all DEC programs were to be used together with a host 
program, DEC could be devoted to solely the data 
entry/terminal management tasks which motivated it in tne 
first olace. Access to data bases and other files, complex 
data checking, and complex program logic could be left to 
the host. The following scope for the DEC language was 
defineds 


DEC is a special-purpose programming language in 
which data entry forms and activities utilizing 
forms/block mode terminals may be expressed. This 
is to include the definition and documentation of 
forms, the specification of elementary data editing 
and checking, the specification of type 
conversions, and the specification of the 
correspondence of data record fields with form 
fields. 


This definition guided language design. The language 
designed, which is described in separate documentation, is 
primarily declarative in nature; it includes no explicit 
verbs. Actions are implied by the declarations (for 
example, type conversion actions are implied by the 
declaration of data types), but no actions are explicitly 
coded by the programmer. A sample DEC program is included 
at the end of this paper. It is heavily commented to 
explain the teatures of the language, ° 


Terminal management tasks are shared between the compiler 


and the runetime support library, "DECLIB". All terminal 
manipulation may be performed via library procedures, and 
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DEC-generated procedures. There is a single entry point to 
DECLIB for all functions, regardless of terminal type. The 
DECLIB procedures are internally structured in such a way 
that additional types of terminals may be easily 
accomodated, while requiring normally only a single line in 
each application program to be changed to take advantage of 
these additional tyves. 


Since DEC is a compiler, it inputs a source language file, 
and outputs RBM’s in a USL file, and thus may be used 
during coding and program entry from any sort of terminal. 
It may be used either interactively or in patcn. 


The DOEC language has been designed so that it documents 
forms very well, aS may be seen by examining the sample at 
the end of this paper. All features of the display are 
evident from even a rapid examination of a source program. 
In addition, the programmer has great tlexibility in 
placing comments ina DEC program. ‘nis encourages good 
documentation. 


S. what nave the results been? 


Tne six goals for the DEC language nave substantially been 
met. A six hundred line FORTRAN program has been reduced to 
two nundred lines of FURTKAN and about one hundred lines of 
DEC. Again defining “power" loosely, since one line of DEC 
replaced in this application four. of FORTRAN, DEC may pe 
said to be roughly four times more powerful than FORTRAN. 
This implies that DEC programs cost about one fourth as 
much to write as equivalent FORTRAN programs, and this has 
indeed peen our experience. All programs converted to use 
DEC, regardless of language, were substantially reduced in 
size. 


AS an additional benefit, unintended but very welcome, all 
converted data entry programs now work on all our HP264xX 
terminals. This is despite the fact that individual 
programs were originally implemented for a particular 
model, such as the HP2645A, or the HP2640B. In addition, 
there is now complete freedom to use page or line mode. 
The programs were formerly hard-coded to use one mode or 
the otner. 


Programmers have learned DEC in avery short time. A 
single afternoon is sufficient to read the manual and begin 
applying DEC to actual problems. Since DEC is 
Straignt-forward, concise, and "natural," programmers find 
it easy to use. 


Changes to a form, and to its associated data entry 
program, can now be made in a single afternoon, and in many 
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cases in much less that an afternoon. Formerly one or two 
dayS or more could be consumed in such changes, depending 
on the extent of the change. Using DEC, a form can be 
entirely reorganized, and pe back in service the same day. 


6. Can you summarize all this? 


In general, there are circumstances in which 
special-purpose programming languages can be used to good 
advantage. The design, implementation, and adoption of 
such a language can often be justified ona cost basis. 
While language design is a difficult art, analysts and many 
programmers with appropriate experience should be able to 
construct a language which would provide the desired cost 
benefits. Several options are available for implementing 
the language. Tne cost effectiveness of these options 
depends in part on the experience of the programming staff, 
and in part on the expected cost savings from use of the 
language. 


An example has been presented for which available software 
products were unable to fill a welledefined need. Goals 
were established which upon examination indicated that a 
special-purpose programming language would be a viable 
method of obtaining a satisfactory software product to fill 
the identified need. An appropriate language was designed 
anda implemented using a compiler and host’ language 
arrangement. The result was that the goals which had been 
established were substantially met, and in fact the cost of 
producing software using the new language is significantly 
lower than the cost of similar software produced without 
this tool. 
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# <eee LIVES BEGINNING WITH "*" ARE COMMENTS 
<< COMMENTS MAY ALSO BE ENCLOSED IN ANGULAR BRACKETS >> 


SCONTROL USLINIT,LIST,SOQURCE,MAP,CODE 

* Note that compiler control is similar to HP compilers. This 

* specifies that a listing is to be produced, that it should 

* include the source images, a symbol map, and code. Code output 
* is in an assembly-like format for readability. 


REESE EERE EKER KEKE RE RAR RRA REESE EEE EERE EER RK KER EEE REE EKER EEE REESE 


* A DEC program consists of a declaration of a form, tollowed * 
* by one or more “data entry," or "DE," sections which declare * 
* data entry information associated with the most recently * 
* declared form. * 


KHEEKE EAE EEE REE RE EEE KARR EEE EKER RAE KEKE REE EA EKER KEKE KEKE ERERESEREES 


“FORM FORMPROC << name of procedure will be FORMPROC >> 
<< You could call this procedure in CUBOL with °’CALL FOKMPROC >> 
<< USING . . . Or in FORTRAN with CALL FORMPROC(. . .) >> 


0,0,"THIS IS A SAMPLE FORM" 
* Tnis statment says, beginning in row 0, column 0, place the 
* following datas: "THIS IS A SAMPLE FORM" 


2,;0,"°* 7 tt 

* This statement says, beginning in row 2, column 0, place a 
* two character unprotected field. Tne initial contents of 
* this field are to be " ", 


3530.77 Xe" 
* Same as last statement, except row 3, and initial contents OK 


4,0,"'B°xx’*" 
* Same as last, except row 4, and the "XX" is to be in inverse 
* video (display enhancement B). 


5,4,"\CIDTHIS WILL BE IN ALTERNATE CHAR SET C, ENHANCEMENT D" 
* At row S, column 4, place the specitied data using alternate 
* character set C, display enhancement D. 


LABEL: 12,12,"DATEs: !B8° °/*° “s*% ¢™ 
Tne terminal operator will see "DATE: / ¢ ™, the last eight 


B). Note that there are only six unprotected characters. Even 
though these six unprotected characters are in three separate 


indicates to DEC that all six characters should be considered 
a single data tield. The label also allows reference to this 
field in a later data entry section, 


MH HHH HM HH 


-MROF << end of declaration of this form >> 
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Characters of which will be in inverse video (display enhancement 


unprotected fields, the fact that the field has a label ("LABEL") 


“DE IN=INPUTPROC, OK=OKPROC 


<< Declare data entry information associated with FORMPROC >> 
<< Can later in host program CALL. INPUTPROC(. . .), etc. >> 


<< we can reference fields defined in the form section FORMPROC 
<< only by referring to labels declared there. "LABEL" is the 
<< only such label in this example. 


0,4,P,LABEL?; VERIFY NUMERIC*NO“-BLANKS; SAVE 

<< Beginning in byte zero of a data record, there is a 4=byte 
<< long, packed decimal field. Its data source is the form 

<< field labeled LABEL. Verify that the data input by the user 
<< on the form is all numeric, with no blanks. After data has 
<< been successfully input, and you go back to erase all the 

<< unprotected fields in the form, do not erase this one, SAVE 
<< it. 


form section. Totaling of fields and auto incrementing or 
decrementing of field contents may all be specified. 


et 0H HH 


“ED << ends the data entry section >> 


>> 
>> 
>> 


>> 
>> 
>> 
>> 
>> 
2? 
>> 


In addition, data editing (including justifying, blank and zero 
filling, and the like) can all be specified. Constants may also 
be specified as a data source, instead of a field declared ina 


HERE KERR EE RK ERA EEA REE RE REA EES EERE EERE EERE SER EERE REE REKERERKEREEESE 


* 
* 
x 
* 
* 
* 
* 
* 
* 
¥ 
* 
* 
* 


The host language program would be similar to the following: 


OPENDETERM(CBUF,. . «)f << OPEN THE TERMINAL FILE (DECLIB) >> 

FORMPRUC (CBUF ) 3 << DISPLAY THE FORM >> 

INPUTPROC(CBUF,. ~« ©)? << INPUT DATA FROM THE FORM >> 

<< USER MAY HERE DO ANY DATA MANIPULATION DESIRED. IF NOT 
SATISFIED WITH DATA ENTERED, RE*EXECUTE THE INPUTPROC 


STATEMENT AFTER GIVING USER A DIAGNOSTIC. IF ALL IS OK, THEN 


CONTINUE. >> 
OKPROC(CBUF,. « «)# << ERASE SCREEN EXCEPT "SAVE" FIELDS >> 
<< REPEAT THE INPUTPROC/OKPROC SEQUENCE UNTIL ALL DATA IS IN >> 


He He eH HM HHH HM HM H 


CLOSEDETERM(CBUF,. « «)? << WHEN ALL DONE CLOSE FILE (DECLIB) >> #* 
KKKRERK ARR ERE REE EERE ERE AE EERE REESE EERE KARE EER EERE KKK EK KKEE EERE EEERS 


“END << ENDS DEC PROGRAM >> 
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ABSTRACT: 


Most HP users use Teletype or teletype-compatible terminals. Such terminals 
cannot be "multidropped" to allow several to share one telephone line. Neither 
do they incorporate retransmission-on-error, so high-speed operation (above 
1200 bps) is often subject to unacceptable error rates caused by normal 
telephone network noise. But high speed is desirable to minimize operator 
wait time during interaction with the system. 


In the past, minicomputer users wishing to support several CRT's and a printer 
at a location remote from the computer have had to use several phone lines 

(each equipped with modems) or use time-division multiplexors (TDM). The 
weaknesses of the TDM are that it is inefficient and provides no retransmission- 
on-error. 


The microcomputer has permitted implementation of a new generation of concen- 
trator or "statistical multiplexor" which provides end-to-end error control 

and dynamic bandwidth assignment on the shared telephone line. The MICOM 
Micro800 Data Concentrator is the first statistical multiplexor to be designed 
specifically to meet the needs of the minicomputer user. It costs no more than 
a TDM. As a result it can be used in a cost-effective manner on the relatively 
short-distance telephone lines which are characteristic of the minicomputer 
system user rather than the large corporate network. 
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ABSTRACT 


This article deals with programming techniques to 
generate maintainable programs which will survive the loss 
of their author. It is geared primarily for the individual 
programmer rather than the leader of a programming team but 
it should be useful to both. The techniagues described apply 
both to the creation of an entire program or only to the 
Creation of one subsystem, as is the case in a team effort. 
One of the desires of the author is to promote "Lgoless 
Programming" with overall program quality rather than 
individual programmer mystique as the end result. 
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FORWARD: 


The purpose of this article is to discuss programming 
technigues which will aid in the maintainability, hence the 
ultimate survival, of programs. I take as a basic premise 
that few if any programs are ever written such that they 
never require modification. This modification may be 
necessary due to changes in program requirements, operating 
systems, host computer, etc. or to ‘Bugs’ found in the 
program. Whatever the reason, very few programs escape the 
need for maintence. As a corollary I purpose that in many 
cases the modification of a program will be made by someone 
other than the original programmer. In general programs 
tend to be written to satisfy the needs of a particular 
site and thus tend to remain at that site even after their 
original programmer has left in search of a better 
position. The conclusion that must be drawn is that in 
general a program will have to be modified and that such 
modification may be done by other than the original 
programmer. 


If I may digress a moment into historical speculation: In 
the early days of computer programming the prime constraint 
on the programmer was his hardware. Hardware tended to be 
bulky and extremely expensive. As a result an installation 
would have to operate on the least amount it possibly 
could. One of the main hardware restrictions was the amount 
of real memory available in the computer. Virtual memory 
systems came along later to ease the situation but they 
brought with them penalties in program speed and 
complexity. As a result much emphasis was placed on coding 
a program such that it required the least amount of memory 
possible. Programming techniques developed with this goal 
in mind. For example; Variable locations might be reused 
for several purposes as the program progressed. This saved 
using a separate location for each use but made it 
difficult to determine the exact contents of that location 
as the program ran. Sections of code were often overwritten 
with data arrays after they had been executed. This 
technique saved much memory but could be very confusing if 
a modification tried to use the overwritten code. A 
Similiar technique was to modify a section of code in order 
to configure it to perform various functions as the program 
progressed. This was done primarily in assembly or machine 
language but it too could cause much difficulty for someone 
not aware of what was being done. 


All of the difficulties mentioned were dismissed by the 
programmers by explaining that they were smart enough not 
to do anything like that. While this might seem to be a 
valid argument I shall draw on my speculative history to 
discredit it. Hindsite shows us two basic occurences. 
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First, as I have mentioned, these programs were often 
required to be maintained by other programmers after the 
Original author left. This means that someone else would 
have to learn what tricks had been used in order to avoid 
errors. If the programs were well documented and told just 
what had been done then this would be no serious problen.,. 
This was generally not the case. Program documentation was 
skimpy and often even misleading. I attribute this fact to 
the programmers ego and his sense of survival. Remembering 
that the prime method for determining a good from a bad 
program, and by association a good from a bad programmer, 
was how little memory was used, the programmer was 
naturally reluctant to reveal all the tricks he used to 
achieve this objective. By keeping these techniques to 
himself he would be better able to stay one step ahead of 
his competitors and boost his own ego or ‘mystique’. 
Extensive documentation was often omitted as a time 
consuming task with little reward for the programmer. Thus 
the program documentation was not sufficient to allow 
another programmer to modify or maintain the program. 
second, even if a programmer was modifying his own program 
at a later date he might have forgotten all the tricks he 
had originally used and thus fall into the same traps as 
the outside programmer. 


The result of these types of problems often was that 
programs became ineptly patched, slower to execute, and 
unreliable. As an end result they would have to be thrown 
Out and a new program written in their place, even when the 
changes to the original program were all small ones. We 
have set the stage for much duplication of programming 
effort and a bad reputation for the computer industry due 
to the unreliability of its programs. 


What of the present and future? While technology has been 
advancing at a blinding rate and removing most if not all 
of the original constraints on the programmers, they have 
failed to update their techniques to keep pace. Memory cost 
and bulk has been so reduced that most installations can 
now afford to buy essentially all they need. With the 
advent of high speed Secondary storage devices, (drum, 
disc, and soon magnetic bubbles), virtual memory systems 
become much more viable. What we have then is a totally new 
environment for the brogrammer. In the past he had to 
conserve memory by whatever means possible but today he can 
sacrifice some program size for Clarity and 
maintainibility. 


The rest of this article will deal with methods to write 
programs such that they will (1) accomplish their 
Objectives reliably (2) be as Simple as possible to 
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maintain and modify, even by a programmer other than the 
original author (3) possibly survive and remain in use long 
after the original author has gone. It is my contention 
that the ability to write simple to understand, reliable 
programs that remain in use is a far better goal than to be 
thought a “magic man” for the ability to write programs 
that no one else can understand. 


The first sections of the article deal with general 
technigues that might be applied to any computer system. 
The remainder of the article deals with special techniques 


that may be used in order to write programs for the HP-3000 
system. 
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PROGRAM STRUCTURE 


The term STRUCTURED PROGRAMMING has kecome a popular buzz 
word in todays society. As such its definition has become 
so twisted as to make it almost a useless term. Let me 
define what I mean when I say that a program should be 
properly structured. 


A program may be thought of as existing at several 
different levels. The outermost level is the grossest look 
at the program and answers the guestion. Just what is this 
program going to do ? or Why was this program written ? The 
next level breaks the program into major functions or 
“blocks”. For example, there might be an initialization 
block, a function selection block (if the program has 
multiple functions), a block to perform each function, a 
block to deal with anticipated error handling, and a block 
to handle any finishing housekeeping, such as closing 
files, printing summaries etc. 


Each block within the program may then be further 
divided into smaller sub-blocks. A sub block might contain 
the code to read the input file, or to perform a sort on 
the data etc. The key thing about a sub-block is that it 
must be small enough to be fully comprehended by someone 
reading the program. This means, in practical terms that it 
should absoultely be no longer than one page of source 
code, preferable about one half page in length. One and 
only one operation should be preformed in the sub-block. 
Thus it would be improper to create a sub-block that reads 
and sorts the input file if indeed those are two separate 
operations. The beginning of each sub-block should have a 
comment that describes the operation to be performed and 
the person reading the program should be able to verify 
that the code in the sub-block does indeed perform just 
that operation. 


This approach to structuring a program is also known as 
the "Top Down" programming method or the method of 
"sucessive redefinition.” Many papers and books have been 
written about these methods and I will not elaborate 
further here except to say that I normally only follow the 
methods in gross structure but not in actual 
implementation. Some of them involve large amounts of 
formal structuring that I see as time consuming and 
appropriate only for the largest of programming tasks. For 
most programs it is only necessary to keep the concepts in 
mind during the programming, not to generate large amounts 
of paperwork. 
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THE PROGRAM DEFINITION STATEMENT 


At the start of each program there should be a conment 
that states the exact purpose of the program. It should 
answer the questions "Why was this program written ? What 
does it do "? The answers to these questions night seem all 
to obvious at first but thelr answers must be fully 
understood in order to direct any further development of 
the program. I was surprised to find the large number of 
programs that were written and actually being used without 
stopping to ask just what it was that they were trying to 
accomplish. An example might be a program that was written 
to "analyze the system log files". While this might sound 
like an admirable objective, it leaves many questions 
unanswered. Will this program allow me to print a report 
showing the number of power failures logged on a given day 
of the week ? Can it tell me how many lines each of the 
system users have printed on the line printer ? Depending 
on the answers to this type of gquesticn, the program might 
be a small task or a major programming effort. No program 
should ke attempted with so skimpy a definiticn. A better 
statement of program function might be: "This program was 
written to read the system log files and to produce a 
summary file. The summary file will be one record for every 
job or session run and contain the total number or records 
transferred to each I/O device by that job." With this 
definition it is easier to tell just what the program will 
Cr will not do. | 


The program should adhere rigorously to its stated 
objectives. This is a means of avoiding the program that 
starts out to do a simple task and ends up grcwing in to a 
monsterous “klugde” that attempts more than its modest 
Original framework can support. The temptation is great to 
take a program that does “almost exactly’ what ycu want and 
aad to it until it can perform both the old and the new 
function. The problem with this is that the groune rules 
for the program are being changed. For example, a program 
that was designed to read the system log files and print 
out a summary of powerfails might be a candidate to be 
built into one that can also produce a summary of I/O 
errors by device. Then it might be modified to create job 
summaries and print histograms of system usage (CPU or 
CONNECT TIME). This sounds like a viable thing to do since 
the original prcgram already has the code necessary to read 
the log files and extract some of the information. It seems 
that a lot of time might be saved by avoiding the 
duplication of that code. I do hereby put it to you that 
you should avoid this pitfall like the plague! "Why"? you 
might ask. The problem arises in the fact that at the time 
the original program was written certain decisions had to 
be made as to the best way to handle the task. These 
decisions were made based on the original design objectives 
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of the program. By allowing the design objectives of the 
program to change after the fact, you may have locked 
yourself into some no longer valid decisions. For instance, 
when the original decision as to how to handle reading the 
logfiles (whether to read record at a time utilizing the 
file system or to invest the time necessary to write a 
special internal deblocker) was decided, the size of the 
task at hand could not justify the time spend in writing an 
internal deblocker vs the time lost in reading the few 
powerfail records. Thus the slower file system was used to 
read the records. In the later version of the program it 
would make a great deal of sense to do internal deblocking 
of the log records since the volume of recorGés read was now 
very great. At this point, the program is already locked 
into the record at a time scheme of reading the log files 
and could not be easily converted into a new scheme. Thus, 
by revising the design objectives of a program you might 
have ended up with a program that has a much poorer 
performance than desired, or you will end up spending far 
more time to convert the old program to a more efficient 
scheme than if you had just started from scratch. 


A further effect of allowing the design objectives to 
change after the program is written is that the program 
will end up looking “LUMPY”. By lumpy, I mean that you will 
be able to see that the original program shell is here, and 
a “LUMP” has been added here for this function, another one 
here, one there and so forth. In the end the program may be 
so lumpy and consist of so many different internal 
technigues, variable names, that it will be almost 
impossible to find and fix any bugs that it has. Indeed if 
allowed to continue, the program modifications will 
eventually create a program that is non functional and non 
maintainable, in short, totally useless. 


If there is any question as to how much the initial 
program definition statement should encompass, I suggest 
the following guideline. Make the original program 
definiticn ccver as large an area as the program will ever 
be allowed to perform. You may add gualifiers to the effect 
that it is envisioned that the program will perform these 
functions at a later time and that they are not completed 
at the present time. You may then plan the program such 
that these non-implemented functions will be possible, even 
to the point of including dummy program blocks to mark the 
places they will be added. In this way the initial 
decisions on the methods used by the program will be valid 
even if the program is expanded to its maximum. 


The program definition statement serves two functions: 
First, it informs the person reading the program source as 
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to just what to expect this program to do (and conversly 
what to expect it not to do). Second, it serves as a guide 
as to what modifications fall into the original concept of 
the program, and thus are vaild changes to it, and what 
functions are outside the original concept and should best 
be handled in another manner. The program definition 
statement should always reflect the current status of the 
program but should be changed only after a great deal of 
thought and soul searching. 
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MAJOR PROGRAM BLOCKS 


The structure of a program should be broken down into 
major blocks, each block responsible for a certain 
function. A function might be best described as that 
section of the program which performs a logically related 
set of tasks. An example might be for a program that is 
designed to read the system log files and then either print 
a summary of powerfailures or write a summary of the I/O 
written for each job or session run on the system. A 
possible division into functions might include the 
following functional blocks: 


Initialization and selection of the desired function. 


Extraction of the powerfail records from the log files 
and the accumulation of summaries. 


Printing the powerfail summary. 


Extracting the 1/0 records from the log files and the 
accumulation of summaries. 


Printing the I/O summary. 
Handling any internal errors or file errors encountered. 
Closing the files and finishing up. 


Notice that not all functions need be performed for each 
execution of the program. 


At the beginning of each block should be comments that 
describe exactly what function that block is to perform. 
This is similiar to the program definition statement at the 
beginning of the program. The same rules apply to the block 
definition statement as applied to the program definition. 
That means that the block definition statement should 
rigorously define the function of that block. No deviations 
to the block’s function should be allowed without verifing 
that the statement will still be valid. Also at this pcint 
any interconnections, common files, etc. between this block 
and any other block should be stated. 


This structuring by functional blocks will make the 
program easier to modify and maintain. Thus if the program 
is having trouble in the selection of a function, only the 
block containing that function need be examined. If you 
desire to change the format of the powerfail summary 
report, you again need to modify only one block. A 
necessary feature of the program blocks then is that they 
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must be relatively independent. This will allow you to make 
a change in one block without affecting the function of the 
Other blocks. 


In certain cases it is necessary that two or more blocks 
will have to have a certain amount of interconnection. In 
the above example, for instance, the block that reads the 
logfile records and accumulates summaries must pass those 
Summaries to the block that prints them. Also, if any block 
encounters an error that is being handled by the errors 
block then certain information about that error must be 
passed. In this case the functional blocks can not be 100% 
independent. In order to maintain the desired degree of 
maintainability to the program all that need be done is to 
ridgidly define the interface between the blocks. This 
might take the form of describing the parameters passed 
between subroutines or the layout of the program common 
areas. It becomes important to also include a description 
of just what values each block can modify in these 
communications areas. Careful attention to detail in 
defining the use of these interconnection areas will save 
untold problems later in the program life. I strongly 
suggest that this documentation take the form of comments 
within that actual source code rather than as a separate 
document whenever possible. This will insure that it is 
always carried with the program and not misplaced or lost. 
Once the usage of the interconnection areas has been 
defined and the program written, it should be strongly 
discouraged that any programmer be allowed to redefine them 
without carefully examining the entire program for 
consequences. Any such redefinitions should also be noted 
alongside, not in place of, the original definitions. In 
this way any problems of interconnection areas being wrong 
can easily be traced to the offending block. 
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PROGRAM SUB-BLOCKS 


Within a program block the program should be broken up 
into sub-blocks. Each sub-block should be a Single entity 
that performs only one operation. The size of the sub-block 
should be such that it can be easily comprehended without a 
great deal of effort. The ideal situation is where a 
sub-block can be quickly scanned and verified that the 
operation is actually performed correctly. From practical 
experience this relates to from one half to one page of 
source code. 


The sub-block should begin with a comment that states the 
Operation to be performed. Again, this sub-block definition 
statement is important in that is serves as the guiding 
rule for the sub-block. The function of the block should be 
reflected by simply reading the sub-block definition 
statements. 
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THE RULES OF BLOCKS 


The block or sub-block is a special animal. In order to 
be useful several rules must be rigidly followed. Failure 
to do so may result in a program that only has the illusion 
of being properly structured. The rules are: 


1). 


2). 


3). 


4). 


The only place for entry into the block’s code is at 
its beginning. 


The only place for exit from a block’s code is at its 
ending. (The only exception should be an error exit 
ESCAPE) 


Only certain easily recoginzable programming 
constructs will be allowed within a block. This list 
includes but is not limited to: 
a). straight line code (statement follows statement) 
b). if then else 
Cc). locping (DO UNTIL, DO WHILE, WHILE DO, 

REPEAT n TIMES, DO FOREVER, etc.). 
d). case (execute exactly one of the following) 
e). escape (escape a loop prematurely or error exit) 
Certain programming constructs are to avoided 
whenever possible. These include but are not limited 
to: 


a). I1l1 defined or ambiguous branches (FORTRAN ‘S 
ASSIGNED GO TO, certain cases of COBOL’S PERFORM, 
FORTRAN “S COMPUTED GO TO while not as bad as an 
ASSIGNED GO TO should still be avoided) 


b). Backward branches. The major program flow should 
be strictly from top to bottom. Any backward 
branching should always be a part of one of the 
constructs in rule 3 and should be easily 
recognizable as such. (For example, FORTRAN will 
not support the DO FOREVER statement but it can 
be simulated by a single backward branch (GO TO). 
In this case comment statements should be used to 
Clearly mark the code as a DO FOREVER. 


These rules are not all encompassing nor are they 
inviolable but they do represent a collection of guidelines 
that I have found lead to programs that will survive the 
test of time and maintenance. Not all rules can be 
implemented in all languages but the concepts should apply 
to any language where the user has ccntrol of the program’s 


flow. 


In cases where the syntax of the language used does 


not support a construct, the construct can usually be 
Simulated using other features of the language. Always make 
sure that it is obvious which construct is being used. I 
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recomment sticking to those constructs listed since that 
comprise the most commonly understood constructs. One of 
the objectives of structuring your programs is to make them 
readable by others. 


The reasons for avoiding such constructs as FORTRAN’S 
ASSIGNED GO TO is that they make it very difficult to 
interpret the program flow. The destination of an ASSIGNED 
GO TO is not known until actual program execution time. 
This makes it very difficult for someone reading your code 
to determine how your program functions without actually 
Simulating its execution thru exhaustive cases in order to 
find all possible values of the assigned variable at this 
point in the program. FORTRAN’S COMPUTED GO TO has some of 
the same problems in that it is a multidirectional branch 
but at least the possible targets of the branch are listed 
in the statement. This statement may be used to construct a 
CASE statement but it should be clearly marked that this is 
so. Also note that all CASE statements will eventually 
return to the same point in order to properly terminate the 
statement. COBOL’S PERFORM verb can cause much the same 
confusion as FORTRAN’S ASSIGNED GO TO when it is used to 
perform different subsets of the same set of paragraphs. 
This makes it very difficult to determine if execution of 
the paragraphs will have the desired result. This also 
violates the rule of always entering a block at the top and 
exiting at the bottom or it confuses the definition of the 
blocks. 
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PROGRAM DESIGN VERIFICATION 


The program definition statement should state just what 
the program is to accomplish. By reading the block 
definition statements it should be possible to see just 
what blocks should be involved in any subset of the 
programs operation. it should be possible, then, to verify 
if the blocks within the program are capable or satisfying 
the program definition statement. You should also be able 
to single out any block that is nct necessary to the 
programs operations. 


NCw that the program definition can he seen to be 
Satisfied by the block definitions it is necessary to 
determine if the blocks actually do what their definitions 
Say they do. This is accomplished by reviewing the 
Sub-block definitions. You should be akle to follow the 
blocks structure thru each of the sub-blocks, remembering 
that all entry into the block is at its top and all exit 
from its bottom, thus all branching must be between blocks. 
If the rules of blocks have been followed it should be a 
Simple matter to follow the program thru each sub-block, 
accepting the sub-block definition as aescribing properly 
the action of that block. 


Once each block is verified to perform properly, given 
that its sub-blocks perform properly, all that is necessary 
is to verify that each sub-block will satisfy its 
definition statement. This is the first time that we must 
actually read the source code in the task of determining a 
programs correctness. If the code within the sub-blocks 
follow the rules of blocks and is of sufficiently small 
size then it should be a simple matter to verify that each 
one properly performs its function. 


At this point the program will have a very good chance of 
performing the program definition as stated at the 
beginning of the program. If there are any problems then it 
should be easier to isolate them by placing debugging 
statements at first the interfaces between the blocks, then 
at the interfaces between the sub-blocks and finally within 
the sub-blocks if necessary. In this manner, you cen 
eliminate the majority of code, simply by eliminating the 
functions and operations that are not in error. If the 
program has been properly structured then isolating a 
problem can be the easiest rather than the hardest part of 
debugging. 
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By the same tcken, program modification has alsc become 
much easier. In order to change a programs cperation follow 
the following steps: 


il). 


Z2). 


3). 


4). 


5) 
6). 


7). 


Lxamine the desired change to determine if it fits 
within the program definition statement. If not then 
seriously consider not making the change but rather 
writing @ new program as any such change will have 
major ramifications. 


Determine which block performs the function that needs 
to be changed. Alsc consicer at this time if the 
change 1s in reality a new function, in which case it 
should have its own block. 


Locate the suk-block within the block that is 
wertorming the operation to be modified or determine 
where in the blocks program flow a new sub-block 
should be located. 


Make sure that the changes will not alter the block 
definition statement. If so then the entire program 
structure will have to ke examined. If not, then you 
will only be concerned with this block. 


If the changes are within a sub-block, make sure that 
the sub-block definition is still valid after the 
changes. 


If you have altered the program flow within the block 
then make sure that the sub-blocks and program flow 
will still satisfy the block definition. 


At this point, if the definition statements are still 
valid, the progran flow is still good, and the rules 
governing the interccnnecting areas have nct been 
violated, the modification should be properly 
installed. Now go back and exercise the program 
thoroughly in and around the affected functions to 
verify proper operation and to verify that the 
modification functions properly. 
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COMMENTS AND DOCUMENTATION 


A few words need to be said about commenting and 
documenting a program. In the past this task was ccnsidered 
as separate from writing the program. Indeed, in many 
cases, the person writing the documentation was not the one 
that wrote the program. There are times when this approach 
is not bad, especially when the documentation in question 
takes the form of an extensive users manual. It would be a 
misapplication of talent to have a good programmer tied 
down for six months after each program, writing a book on 
how to turn cn the system etc. The thing to bear in mind in 
the case of Gocumentation is that there may be various 
levels of -it. Some levels of documentation are best handled 
by full time documentors as in the case above, but there is 
e level of documentation that is the responsibility of the 
programmer ane should always be done by them. This 
documentation consists cf the comments within the program 
source, and akasic functional description of the program. 
The main use of this documentation will be by thcse persons 
that will have to maintain and modify the program. This 
means that the task of cGocumenting shoule not have to ke an 
exhaustive effort as the persons using it will at least ce 
experienced programmers. All that is necessary is to 
explain the basic flow of the program and the major 
decisions about the program’s design. 


In many cases, documentation by the programmer has been 
put aside until the end of the program developement cycle. 
This was often justified by citing tight schedules, 
uncertainty in the programs final state etc. Documenting 
after the fact leads to skimpy or inaccurate Cocumentation 
at best and possibly even to no documentaticn if the 
schedules are in reality tight. 


It is imperitive that the programs internal documentation 
be written as the program is written. This will insure that 
it truly reflects the actual state of the program. In 
attempting to go back after a program is in use and 
document it, the reasons a certain technique was used is 
often forgotten. The reascns for choosing one technique 
over another is one of the most important things to know if 
you are contemplating a modification to that technique. It 
would take little actual time for the programmer to add a 
few comments at the top of a block or sub-block explaining 
how the block functions and either why the technique was 
chosen or a brief notice as to under what circumstances it 
would not be appropriate. This accomplishes a dual 
function: It informs the next programmer, or indeed 
yourself if you come back to this program at a later date, 
as to when to consider modifying the technigue. It also 
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forces you to consider such questions as applicability at 
the time you are writing the program rather after a 
technique is already locked into the program. It is far 
better to discover that a technigue will not work in all 
cases before it is installed rather that having to remove 
and replace it after a program is finished. 


The time to write the internal program documentation, 
then, is while the program is being written. The place to 
put the it 1S as comments in the program source code. This 
makes sure that whoever is responsible for maintaining the 
program will always have accurate documentation at hand. At 
first it might seem that by documenting as the program is 
written will take too much time. Upon closer examination 
and by actual trials it can be determined that just the 
opposite is true. Tne exercise of documenting as you go 
will force you into thinking out just what you are doing 
and consecuently keep you from following toc many incorrect 
paths. The end result will be that in the time that you 
could have written but not documented a vrogram, you can 
have written and documented a program that has a much 
better chance of being correct. At the very least the 
program will be much more maintainable. 


What constitutes good commenting within a program? 
Contrary to the beliefs of a lot of programmers, the more 
comments does not imply the better the documentation. It is 
the quality of the comments not the guantity that 
determines the quality of documentation. In fact, good 
documentation can ke ruined by adding a lot of unnecessary 
comments and making it difficult to weed out the essential 
information. I offer to you the following model. It has 
proven to be useful to me in the programs I write. 


1). Variable and Program Names: 


Variables, subroutines, and programs should be nared in 
such a way as to make their use as obvious as possible. 
Thus it might be eaSler to relate to CUSTOMER(INCEX) in a 
program rather than to C(I). I realize that certain 
languages place restrictions on names. These restrictions 
are being lifted as the languages grow, for instance 
HP-3000 fortran ncw allows names to be fifteen characters 
long rather than the old five character maximum. In any 
case try to avoid the naming of items within a program by 
arbitrary or cryptic names. The best way I know to make a 
program almost unmaintainable is to go thru it and replace 
all the variable names with a sequence of meaningless 
names. The names used become an important part of your 
documentation. If they are chosen properly then you should 
have little commenting to do within your sub-blocks. By the 
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serves as rore or less a roadmap to find the block 
responsiktle for the function ycu are interested in. At the 
very least ycu should include the basic program flow thru 
the blocks, a brief Gescription of each blocks function 
and how tc locate it in the source code (subroutine name, 
CLC.) « 


6). Program Modification History: 


A short running histecry of the modificaticns to the 
program should be included next. It’s this history that 
will tell you what changes have been made for each 
revision of the program. Items to be included are: 
revision code after the changes 
date the changes were completed 
a brief description of the changes 
the name of the person doing the modifications if other than 
the original auther. 


9). Author and Modifier Names: 


A short description of the author(s) and of those persons 
responsible for making modifications to the program 
should be listed. This might include the address and/or 
phone number of the persons or any other information 
necessary to identify then. 


10). Data Definition Sections: 


The usage of any data arrays or block interconnection 
areas should be set off and commented in such a way as to 
make their intended use clear. This might be as simple as 
identifying which array is used to buffer data into and 
out of the program or as complex as to describe in detail 
the format of an internal communications array. Comment 
blocking should be used in order to separate the data 
Gefinition areas for the various operations into blocks, 
much as the program ccde areas are blocked. It is easier 
to understand the data structures in a program if you can 
concentrate on only the desired subset of them. For 
example, if the format of the output records needs to be 
modified then it should be a simple matter to locate the 
definitions dealing with it and to be assured that all 
Gefinitions in that area are strictly for that purpose. 
This will allow changes to be made without affecting other 
areas of the program and allow no longer needed variables 
to be discarded. 
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ll). Block Definition Statements: 


Each block within a program should begin with a comment 
describing the operation to be performed within that 
block. The format of the statement and of its data 
definitions should he similiar to those for the main 
crogram. 


12). Suk-block Definition Statements: 


Each sub-block should begin with a very short statement of 
what that sub-klock is to perform. For example "This 
section sorts the input array into ascending order by 
customer name". Very little additional commenting should 
need to be done within the sub-block except maybe for a 
Simple clarification ccmment here and there. If the 
variable names are properly chosen and the proper code 
constructs are being used then the sub-block can be almost 
self documenting. 


If a program is internally documented well then most 
program maintenance and modification can be acccmplished 
with little more than a source listing. If an additional 
document is desired it can often be created by excerpting 
the comments directly from the program, block and sub-block 
headers. 


A word to the modifiers: Once the program has been 
written following all these guidelines, it is your 
responsibility to insure that by modifying it you don’t 
invalidate the original program concepts or documentation. 
A good rule of thumb should be to try to make any 
modifications such that, in the future, you couldn't tell 
your code from the original unless it is so marked. This 
means that you should not force your own programming 
peculiarities into the program unless they match those 
already in use. Use the same variable naming scheme as the 
Original author, even if you can think of a better one. 
This prevents ccnfusion later with having to follow several 
conventions within the same program. Also try to make your 
code look like the original. This might mean doing the same 
indenting and following the same ccmmenting scheme. You 
should also be responsible for updating any internal 
documentation that is affected by your changes. This is a 
good exercise in that it will force you tc examine all the 
areas that your changes might affect. Also don’t forget to 
add a line to the program history records to indicate the 
changes you have made. 
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ang thon resume execution. Again, this is a relatively fast 
oreraticn (maybe 40 microseconds). If the required segment 
is not in nemory then “PE will suspend the program anc make 
a recuest tc the memory manager in orcer to have it mace 
cresent. This process invclves reading the segment from 
Gisc intc mercry and might invclve swanping some cther 
seqrent cut cf nercery to make reoor fer it. Disc transfer 
time on the HF-3U09 is fast but is still orders cf 
ragnituée slower than direct memory access. Swapping a 
seqrent fron. the cisc intG mernory might take éprroximately 
500 te 2060 microseconds. If this operation is reauirea 
infrecuently then it ig not a great buroen but if it must 
occur a dreat number cf tires then it can cause a iocal 
thrashing condition for this crogram. 


How co you ccntrol local thrashing? the main nethod is to 
reduce the number of intersegment sukroutine calls to the 
ninimun. Lets take the program exanple given above. In the 
case of the functicn involving Subroutine A, there is one 
intersegment call at the beginnina of the functicn and then 
one at the enc in order to return to the main program. This 
fits nicely in cur Guidelines. In the second function, 
however, subrcutine & calls subroutine C a great many 
times. 1f these two subroutines are in citferent segments 
then we might enc up in the local thrashing situation. It 
makes sense, then, tc put subroutine B and C into the same 
segqnent. rhat segnent will be a little larger than if they 
were in cifferent seaqnments Eut the time necessary to call 
beck and forth has been qreatly redauced. 


Lets sunnarize what we’ve learnec se far. It is good to 
reduce the size of cur code segments by making a greater 
number of smaller segments. this reduces the total real 
memory requirements for the systern. If we place two 
routines that call each other a lot into separate segments 
then we can cause a local thrashing that wastes time and 
resources. This means that we have some traceoffs tc 
evaluate in the seamentation cf programs. 


here are some time tested guidelines for the segmentation 
Of program code: 


1). Try to make the program segments as small as possitle. 
(4000 words is a good size to shoot for). 


2). Minimize intersegment calls between routines even at 
the expense of larger segments. (Don’t worry akcut 
numbers as small as 10-20 calls per function but 
concentrate on those that misht be called huncreds of 
times). 
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3). Once ycu enter a segment, try to remain in that segment 
for as long as possible. This might mean making a copy 
of a small subroutine that is used by several seanents 
anc adding it (under a slightly different name) to each 
segment that requires heavy use cf it. 


4). Once you leave a segment, try to remain cut of it fcr 
as long as vossikle. 


5). Place large and seldom used sections of code into their 
Own routines and their cwn segments. Error hancélina 
routines that contain a large number cf error messages 
are prime candidétes (Ascii strings occupy a great Geal 
of code space éS ccmpared to machine code). 
Initialization and light user interaction sections that 
require messages to be written anc read are also good 
candidates. It 1s possible that these large sections of 
necessary code might only be called once, or in the 
case of error routines, not at all in the program 
execution. This means thet they will not often need te 
be cresent in real memory. 


liow 1s the best way to seqment our sanmvle program ? First 
of all, we have cetermined that subroutine A can be a 
separate segment. Subroutines B and C should ke in the sane 
segment since they call each other a lot. Subroutine Dis 
the error handling segment so it can be in its own segment. 
The main program ig rarely executed and could ke in its own 
segment. Tne final segmentation would then be: 


SEGMLHT Ls MAIN 

SCGMEWT 2: SGL A 

SESMEWT 3: SUB B and SuB Cc 
SEGMENT 4: SUS D 


Data segments 


MPC currently has the restriction that a programs 
modifiable area must be in a data segment called a ‘stack’. 
It aces not currently allow the data stack to ke split into 
separate data segments. This means that the only control we 
have over data stacks is in their size. A certain amount cf 
data stack will be required for the prosram to execute. The 
areas we can control have to do with data arrays and 
storage and with cynamic storage. 


The stcrage necessary for data arrays declared in the 
main program cr in the golbal or commen areas of a program 
is always ellocatead in the data stack. Anything we can co 
to reduce the size cf this storage area will make for a 
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CCOLLSS PROGRAMMING 


In summary, the main point I am trying to get across is 
that the days are gcne when programming cculd be ccnsidered 
a strictly sclitary project. A program may be written by 
only one person, LEut if 1t is to survive, it must be 
written in such a way as to allow others to maintain and 
modify it. This means that a programmer must give some 
thousht to the basic structure of the program and to 
organizing its internals in such a way as to make its 
operation ckvious tec other programmers. 


I have cutlined several technicgues that might help to 
achieve this cbhjective. There are probably other techniques 
that would also ke useful. You might, for instance, make it 
a prectice to have another programmer try to “read” your 
programs in order to determine if they are properly 
commented and written. This would accomplish yet another 
benefit in that it will be a method to share programnins 
technigues and excertise. By having an experienced 
programmer read the ncovice’s program, he could helr the 
novice to develope the proper standards and technigues. The 
experienced programmer might also learn a few new 
techniques from the novice if he keeps his eyes open. By 
having the novice read the expert’s programs, he could 
learn what techniques should be used in a given situation. 
The expert will be able to sharpen his Gocumentation 
technigues by having the novice identify any ereas of the 
program are difficult to follow. 


A major point of tnis whcle procedure is to combat the 
feeling that a program is the exclusive property of one 
programmer. It should be thought of as kelonging tc the 
entire group or to the company. In this way the programmers 
will not code cryptic programs in order to promote their 
own mystique. They will instead be writing prorams that 
will be understandable by others and as such can survive 
lona after they are gone. A side benefit of writing 
programs that survive should be the writing of more 
reliable code and raising the standard of data processing 
in general. 
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SOFTWARE QUALITY CONTROL 


C. EDWARD McVANEY 
J. D. EDWARDS & COMPANY 


The Predicament 


Computers have brought space age technology to the 
ordinary businessman. Their potential seems boundless; the 
electronic equipment (hardware) is usually superlative: but 
the computer programs (software) can bring a plague to your 
organization. 


The hardware side of the computer industry seems to 
be far more advanced than its software counterpart. The gripes 
and groans about computer failures are not all without sub- 
Stance, and ninety-nine times out of a hundred it seems it is 
the software that is at fault. 


You have to have software! The computer won't work 
without it! But what do you do? How do you protect yourself? 
How do you assure a high quality result? 


Knowing what to look for, and how to judge quality 
software, need not be a great mystery. You don't have to be 
a computer technician to make meaningful value judgments. 
Your common sense will serve you well if you're willing to do 
some research. 


Before we go much further, we should make a clear dis- 
tinction between "systems" and "applications" software. 
Applications software is the term computer specialists use to 
identify major business systems on a computer. For example: 


Payroll Systems 
Inventory Systems 
Billing Systems, and 
Accounting Systems 


Applications software is sometimes referred to as a 
software system, a software package or just a system. In ad- 
dition to the individual computer programs (usually ranging 
from 10 to 100 programs), it would include all the supporting 
documentation and related professional services including 
training and on-going maintenance. 


Systems software, on the other hand, is a term used 
to describe the family of computer programs that are used by 
the computer to do its own work. For example: 


Operating System 
Compilers 

Utility Programs, and 
Communication Monitors 
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2. Systems Documentation - Documentation is toa 


computer system what a shop manual is to a mechanic - it is 
not very important until you need it. Systems documentation 
Should consist of: 


Samples of Each Report 
Illustrations of each Video Display 
Copies of Forms and Documents 

A Glossary of Terms and Codes 
Clerical Procedures 

Computer Operating Instructions 
Program Descriptions 

Data Base Descriptions, and 

Other Appropriate Material 


If these items are not readily available and profes- 
sionally packaged so that they are easy to understand, you've 
noted a serious weakness in the system. You will be vulnerable 
to turnover of personnel and empire building if you don't have 
good documentation. 


3. Clerical Procedures -—- Computer specialists have 
been known to forget about the people who have to use the 
system. Check the clerical operating procedures including the 
video terminal operating instructions to see if they are simple 
and effective. There's no need to explain the mundane, but at 
the very least, the unusual aspects of the system should be 
explained. 


Of course, checking for voids goes beyond the parti- 
culars we've noted here - video displays, operating reports, 
input journals, forms, data bank, accounting controls and so on. 


(b) Fitness to Your Needs 


In their eagerness to sell computer hardware, sales- 
men have been known to recommend a software system that didn't 
quite fit. Major misfits are not uncommon. 


If you are told that your organization can be changed 
or adapted to fit the software, make sure.you know what will 
have to be changed. A good software package should provide de- 
finable improvements to the flow of work within your business 
with a minimum of organizational or procedural changes. It 
had better, because modification costs dearly, not only in 
terms of time and money but, more importantly, because vital 
management data often will not be available while the modifi- 
cation is being done. The "data gap" can be filled, of course, 
by keeping a manual or semi-automated system running parallel 
with the computer, but we can't imagine any business owner want- 
ing to do that for very long. 
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(c) Maintenance Costs 


Good software packages, like good automobiles, don't 
require much maintenance. If a computer programmer has to de- 
vote a significant part of his time to maintaining a software 
System, you can bet it is poorly designed or poorly programmed. 
Conversely, if little or no maintenance is required, you 
should be encouraged. 


The maintenance cost of an acquired software package 
can often be determined by consulting with other users whose 
names the vendor has given you as references. 


(d) Feature Comparisons 


Another effective technique for judging software 
quality is feature comparisons between comparable systems. 
This is basic consumerism. These features include: 


Processing Capacity 

Hardware Requirements 

Management Accounting Techniques 
Data Base Concepts 

Timeliness of Reports 

Video Screen Features 

Audit Controls, and 

Others, as appropriate 


Many of the little "extras" in a software system are 
well worth having. 


(e) Operating Costs 


If a software package does not reduce operating costs 
(clerical salaries, etc.) or provide significant intangible 
benefits such as improved management information or better cus- 
tomer service, then something is wrong. 


Innumberable software systems have been installed with 
the anticipation of reduced operating cost and significant in- 
tangible benefits only to have just the opposite come true. 


Therefore, you should check the "track record" or re- 
ferences of a software system to see if it has performed as 
promised. While you're checking references, ask about program- 
mer maintenance costs. 


(f) Real Response 


Video terminal computer systems should provide for- 
almost instantaneous entry of data, updating of records and 
redisplay of updated. records. Many software packages fall far 
short of this capability. It is not uncommon to find video 
terminal packages that do nothing more than conventional '"key- 
punching" into the video terminals and then process the data 
in the off hours. If this is the case, computer records might 
not be updated until the next morning even though video 
terminals were used for data entry. 
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(g) Technical Support 
| Behind every good computer system there should be 
good people to provide the technical support that, from time 
to time, you may need to rely on. 


Do these people know and understand your business? 
Are they competent enough to get things done? What is their 
track record? Where will they be a year from now when you 
need them? Is this a one man show or a prolessional team of 
computer specialists? You should answer these questions and 
assure yourself of proper support. 


Technical support personnel are all important to the 
success of your system. 


(h) Conventional Technology 


More often than you might expect, computer systems 
are developed using non-standard technology, i.e. offbeat 
programming languages, homemade systems software, and mix ‘n' 
match equipment. Beware of these approaches becitise they in- 
variably create inflexibility, overdependence on support 
personnel, and early obsolesence. 


(i) Data Controls 


Precise control features are essential to the success 
of any software package. Check to see that edit controls 
are installed to check the accuracy, reasonableness and inter- 
relationship of all input transactions. Also check to see 
that input balancing controls are in effect. The system should 
have provision for a complete audit trail of all sensitive 
transactions. This audit trail should balance to master file 
control totals and reference back to the originating entries. 


(j) Predefined Standards 


A very effective way to evaluate the quality of a soft- 
ware system is to compare it to independent standards of 
excellence. 


7 J. D. Edwards & Company has developed such standards, 
establishing criteria for, among other items: 


Systems Documentation 

Input Controls 

Accounting Controls 

Data Base Design 

Computer Processing 

Report Design 

Programming Structure 
Programming Efficiency, and 
Numerous other items. 
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Some Classic Examples 


We have said that you don't have to be a computer 
expert to judge the quality of a software package. Let's 
illustrate how you may judge software quality with simple 
examples of a computer report and an input document. 


(a) Report Quality 


Illustration Number 1 represents a construction loan 
status report for Mr. Charles Louis who is building a new 
home. This report is a classic example of computerized 
goobledygook. Note the following deficiencies which could be 
readily detected by a non-technician. 


1. The name and address were typed rather than print- 
ed by the computer. 


2. The following columnar headings are unintelligible: 


. BR ay ee 

. WM . MB 

. TEL . OV 

eo oY . TY DB 
CD 


3. Note that there are three columns labeled TY. 


4. Even if you understood what the codes mean, how 
would you understand the data? What, for example, does "I" 
mean in the MB column? 
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Mr. Charles Louis was somewhat perplexed. He felt 
insecure because he didn't understand what the report said. 


So he took the report to his CPA and asked him to explain it - 
he was equally baffled. 
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You should not tolerate this kind of poor report 
design in any software package. In almost all cases, com- 
puter reports can be made clear, concise and easy to interpret. 


(b) Input Forms Quality 
Illustration Number 2 represents a form used to cor- 
rect a worksheet in a real estate management system. (This 
form has also reached the status of classic gobbledygook). 
Note the deficiencies which can be readily detected by a non- 
technician: 


1. What do the arrows mean? 
2. What are: 


. OIT# 

. NC 

. JF 

. RES Code 
Fid Code? 


3. What do you enter in the four digit date field? 


iitustration No. 2 


CORRECTING ENTRY WORKSHEET 
INITIALS 


PO PELE CCE CE EEE eg 


AE) Gr RR COLE CT Too 


"Bee DATE RES BLANKS DESCRIPTION 
Cope 
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sé 12 we Ff 7 


DESCRIPTION FLo. ~ BLANKS 
cooc 
ae Bz 83 ; Se 93. 94 
a ey ie teal PETE PET ET [steht 
~~ BLANKS a oO ACCOUNT @ TRANS 
Cope 
CUYS- -(dash) over digit for negative 


The point is that neither computer input nor output 
forms need be as complex as many computer people make them. 
Look at Illustration Number 3, for example, the "Account 
Master Revisions" form reproduced on the next page. All col- 
umn headings are in plain English - not computerese. Codes 
are plainly defined at the bottom of the sheet. There is 
plenty of room to write, and there are no mysterious arrows 


or slash marks. 
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ACCOUNT MASTER REVISIONS 
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The "Labor Cost Analysis," Illustration Number 4, 
shows that computer output needn't be gobbledygook cither. 
This weekly report on a construction project can be easily 
read by a non-expert. It keeps jargon and conlusing abbrevi- 
ations to a minimum. 


The Make versus Buy Decision 


In theory, buying a software package should offer 
the advantages of having: 


Lower start-up costs, and 
Shorter start-up intervals. 


In practice, things don't often work out that way. 
Many experienced data processors are skeptical of these sup- 
posed advantages - particularly when modification or changes 
to the software packages are required. Indeed, the more ac- 
complished computer user often steers clear of purchased soft- 
ware packages all together. 


On the other hand, custom designed and programmed 
software supposedly offers the advantages of being: 


Better suited to your operation needs, 
More flexible, 

Easier to maintain, and 

Less expensive to operate. 


But custom designed and programmed software systems 
are not without peril. If you don't have access to a highly 
qualified team of systems analysts and computer programmers 
(either as in-house employees or outside contractors), you 
shouldn't try to develop a custom system. 


A well designed custom system is, in the long run, 
usually more effective than a purchased system. If your 
needs are unique in any way, and you can afford to do it ‘right 
the first time, you should seriously consider custom designed 
and programmed software packages. After all, you've probably 
custom fit every other aspect of your business, so why not do 
the same with you computer software. 


What It Should Cost 


If software were cheap, the big, experienced users of 
computers would have known it long ago. Experienced computer 
users may invest nearly as much (sometimes even more) in soft- 
ware as hardware. 


It would be nice if one or two thousand dollars of 
software were all you needed, but unless your business fits an 
available ready-made package very closely, you should plan on 
spending anywhere from 40% to 100% of the computer purchase 
price on software, depending on your needs. 
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Once More From The Beginning 


When it's all said and done, what you really want is: 


Better Management Information 

Reduced Operating Costs 

More Flexible Business Systems, and a 
Decent Return on Your Investment. 


Today's computers have the potential to do all of 
that in a most pleasing way - but be careful! 


software - particularly applications software - can 
be the fly in the ointment. 


Check out each component of the system 

Use common sense and be critical 

Ask for professional help in technical areas 
Follow a sound evaluation methodology 

Look for voids, fitness for your needs, mainten- 
ance headuches, effective features and operating 
economics. 

Be very careful about technical support personnel, 
and 

Use predefined standards or evaluation criteria if 
you have access to them. 


Finally, don't be tempted by low-cost or no-cost soft- 
ware purely because of price - or rule out a custom-design 
purely because of high start-up cost. But you're not likely 
to do either if you've been thorough up to the point of cost 
considerations. Remember that old saying .......... 


The bitterness of poor quality remains long after 
the sweetness of low price is forgotten. 
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TERMINAL AND APPLICATIONS MANAGEMENT SYSTEM 

TAMP (for Terminal and Applications Management System) is an 
integrated system of processes and subprograms which are used to 
define and manage an on-line application system. Each application 
to be run under TAMP includes one TAMPFILE, which is a multi-key, 
variable-length KSAM file designed to provide a compact, flexible, 
and easy-to-use interface to the applications environment. This 
TAMPFILE, which will be discussed below, defines all processing to 
be done within the monitor, and includes TAMP terminal configuration, 
user/function security matrix, and all data files to be managed by 
the system. 

The first step in implementing an application under TAMP is the 
creation of the TAMP KSAM file. Here the user is asked questions 
about the size of his application, such as the maximum number of 
functions which he expects to include in the system. If the user 
miscalculates the dimensions of his application, he also has the option 
of later expanding his TAMPFILE, without affecting its data. The user 
also enters the Security Manager's name and password, and in so doing, 
restricts all further modification of the file to the bearer of that 
password. 

The next stage in preparing a TAMPFILE for use is the definition 
of the application. This data is entered through a terminal interactive 
program and is grouped in logical records which represent the resources 
managed by TAMP. These resources are user functions, system utilities, 
data files, terminals, and users. A brief description of each of these 
records, their relationships to each other, and their use in on-line 


processing may be found below. 
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Although the following outline of TAMP record types greatly 


simplifies their structure, it does provide the essential content 


and purpose of each type of record. 


FUNCTION - 


UTILITY - 


FILE - 


There is one function record for each 
callable application entry point. Each 
function may be one of several types 
(program subprogram, SL subprogran, 
independent process, MPE stream) and is 
invoked accordingly. If the function 
expects data file numbers or data from 

the terminal as parameters, that is also 
included here. 

Utility records are almost identical to 
function records. However, those functions 
which are designated as utilities are 
initiated automatically by the TAMP software 
and may not receive parameters or be called 
by users. 

This record contains a filename qualified by 
group and account. The file which this 
record represents may be of any type, 
including MPE, KSAM, IMAGE, and SMOG (described 
elsewhere in this paper). Once defined on a 
TAMP record, a file may be opened by the 
TAMP software and passed as a parameter to 


one or more functions. 
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TERMINAL - This record contains the logical device 
number of a terminal to be included in 
on-line TAMP. For each active terminal 
TAMP record, a process will be created by 
the on-line software which opens and 
allocates the corresponding logical device. 

USER - The user's record includes his name, encoded 
password, processing values, and maps indicating 
which functions he may display on his menu and 
which functions he may actually call (these 
two types of function access are completely 
independent). Also included in this record 
are the assignments by which a user can expect 
each of four terminal soft-keys to call for 
him a selected function. 

The program which defines a TAMPFILE also serves as the TAMPFILE 
maintenance program, and is where the Security Manager really does 
his job. As each user (and user password) is added to the systen, 
the Security Manager also enters which functions that user may see on 
his menu and/or actually call. The Security Manager may also assign 
for each user two application-defined processing values, which are 
handy for such things as data-base user class codes, maximum dollar 
amount which may be entered by the user, or whatever else fits the 
application. 

Other features of the TAMPFILE maintenance program include 
terminal configuration, assignment of data-files to functions (the 
filenumbers or file-tables of these files will be passed as parameters 


to their assigned functions during on-line processing), and definition 
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of system utilities, such as start-up, batch processing or logging 
routines. 

The on-line portion of TAMP is the "outer block” within which 
all application programs will run. The TAMP software will call 
application defined start-up routines, open and allocate terminals, 
display sign-on screens, provide all first-level menus, and call 
requested application functions. This is accomplished through the 
use of a set of related processes which communicate with each other 
through a commonly held extra data segment. 

On-line TAMP is actually a simple, two-level process tree 
consisting of a father process (FATHER'TAMP), and his various kinds of 
sons. FATHER'TAMP is the process which is created upon running TAMP. 
His first duties include initiating start-of-day application processing, 
which may also include restart and recovery procedures, and creating 
the extra data segment which will be used as the common communication 
area between processes. FATHER'TAMP next reads all terminal records 
from the TAMPFILE, and for each creates a terminal sign-on process. 
FATHER'TAMP also creates a process whose sole responsibility is 
communication with the system console, which here becomes the TAMP 
console as well. At this point, FATHER'TAMP suspends himself, and is 
reactivated only by sons with specific requests. All further processing 
depends on input from the user and console terminals. 

The role of the common communication area in the extra data segment, 
as well as the orderly regulation of processes through use of Resource 
Identification Numbers (RINS) is a vital component of the on-line TAMP 
software. However, this processing is invisible to the user and beyond 
the scope of this paper. It should just be considered here that 


‘processes do not haphazardly suspend, terminate, and activate one another. 
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The task of the terminal sign-on processes is simple. Each 
displays a user sign-on screen, and then validates, by user name and 
password, attempted entries into the system. Upon a successful 
sign-on by a user, the terminal sign-on process for that user's 
terminal activates FATHER'TAMP with the appropriate message and then 
terminates. 

Upon notice that a user has signed-on successfully, FATHER'TAMP 
creates a new process for that user. This process displays a welcome 
screen for the user, and, depending on the user's response, may display 
a menu of those functions which the Security Manager has permitted this 
user to see. The user may now request entry into a function in one of 
several ways, including selection by menu position, function name, or 
the user's own soft-key assignments. 

The user's process calls the selected function in the manner 
specified in the function's record (e.g., if the selected function's 
type indicates that the function is a subprogram in one of the Segmented 
Libraries, the user's process will find, load, and jump to this 
subprogram). Also, if the function's record indicates that it expects 
data files and/or data from the terminal, the user process will open 
the appropriate files (if not already open) and pass the necessary data 
as parameters to the function. 

When a user signs-off, control of his terminal is passed back to a 
terminal sign-on process. At the end of the day, FATHER'TAMP again 
takes control, signs remaining users off of the system, initiates 


application-defined end-of-day processing, and terminates. 
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SMOG 


SMOG is a HP2645A terminal interface and screen processing sub- 
system. It provides a convenient access to local and remote terminal 
devices using a wide range of the HP2645A terminal capabilities while 
keeping necessary terminal knowledge to a minimum. 

SMOG makes very few demands on the application programmer. De- 
veloping screen images requires no knowledge of escape sequence char- 
acters. There are no stringent programming requirements necessary for 
accessing terminals in an interactive mode. All housekeeping, work 
areas, buffers and data transfers are handled transparently within the 
subsystem. 

Screens exist in the system as logical records in a KSAM file. 
These records consist of the screen image in displayable form, control 
data and reporting data. Each record has an associated screen name 
which is used as the "key" when adding a screen record to a file or 
recalling an existing screen within a file. Also, there is a control 
record in the file. This contains global file information and sizing 
requirements necessary for allocating buffer space for screen records. 

Working with screens, it is entirely up to the user how they will 
be designed. Then a screen file maintenance program assists the user in 
defining and entering the screen. The user must supply the row and 
column numbers of the start of each field, their lengths, their field 
type: protected or unprotected, any display enhancements and edit 
checking, plus any data which is to be used to initialize the fields. 
The maintenance program then interprets and assembles this data into a 


displayable character string with all appropriate escape sequences. 
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Counters and indexes are kept internally to accumulate read and write 
counts, field descriptions and status information about a screen. 

Once entered, a screen may be easily modified, deleted, displayed, 
duplicated or renamed. Several reports are available including one 
containing a reproduction of the screen image. This report also contains 
a description of each field along with entry numbers which are used to 
address fields in subsequent screen maintenance or to programmatically 
access these fields for changing their enhancements, protection, or 
modifying their data content. 

Screens in one file may be copied in entirety or selectively to new 
screen files. They may also be merged in the same manner with screens 
in other existing screen files. Provisions are included for both 
keeping and deleting another version of the same screen found during a 
merge. 

Programmatically, SMOG has many useful features. One call to an 
initialization program sets up everything necessary to process. It is 
even smart enough to know how its process was started so that a terminal 
can be initialized properly. If a user father process was responsible 
for its creation, it expects that he also assigns a terminal to use, 
otherwise, it defaults to using the logon terminal. Also at this time, 
the caller's screen file is opened, the break key is disabled, buffer 
areas are dynamically allocated and a global work area is set up to 
maintain file numbers and status information which is necessary for on- 
line processing. None of this is ever seen by the programmer. 

The programmer can now interact with the terminal using the screens 
from the screen file. Intrinsics are available to locate screens, to 
modify protected and unprotected data, display enhancements, and protection, 


to output a screen image, to read a screen's unprotected data, and to 
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dynamically create and read from individual fields on a screen. The 
outputting of a screen can optionally include the field at which the 
cursor is to be positioned; all reads from the terminal can be armed 
with a function key interrupt feature which returns an indicator to the 
program, or can optionally be timed out. The programmer has the res- 
ponsibility of calling an intrinsic to reset the terminal before exiting 
from a program. 

SMOG is very versatile. It can alternate the use of both block and 
character mode of I/O. It is callable from COBOL, FORTRAN, and SPL. In 


each of these languages, it allows a simple approach to screen processing. 
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KEDS 


Keyed Extra Data Segments (KEDS) is a method of organizing 
ordered sets of tables within extra data segments. A set consists 
of one or more tables. A table is comprised of one or more elements. 
Access to these tables is permitted by table element within table 
within set. 

This access method allows an application to keep all necessary 
tables "virtually" memory resident while permitting them to be shared by 
several processes within the same job or session. It allows for elements 
to be deposited into a table by a relative element number and retrieved 
by the same element number or by searching for a table element with a 
specific key value. 

KEDS is relatively simple to use. Initially, table space must 
be allocated. This is done by an intrinsic call with which the 
program must supply a set name, the size of the data segments to be 
used, the number of tables in the set and a list containing each 
table description. Each table in a set must be assigned a name, an 
element size, and a maximum number of elements. 

Using this information, KEDS calculates the total amount of 
memory needed and creates as many extra data segments necessary to 
contain all of the user's tables. A parent segment is also created 
through which the tables will be accessed. Therefore, by accessing the 
parent segment, one can determine if an element exists in a table, the 
segment in which it exists, its location within the segment, plus its 
length. Once created, the programmer must load table elements in the 


order in which they are to be used. 
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Elements can be deposited and retrieved very efficiently by KEDS, 
using relative numbers, but, this is not always the easiest or best way 
of accessing tables. If a programmer so desires, KEDS will search a 
table for an element with a specific key value. Keys are not restricted 
to any size or location within the element. Tables can exist which have 
several keys and the choice of which will be used in the search is made 
by the calling program. Tables can be ordered in ascending or random 
key sequence. 

Data transfers are very flexible. One can specify that all, part 
or none of an element is to be transferred if it is found during a 
search. This is a powerful tool for validation tables or tables whose 
elements are suited for multiple purposes. 

The complete capabilities available to the programmer are: create 
tables, append element, update element, read element, read element by 
key (random or sequential), and delete tables. Combined, they provide a 


simplified approach to memory resident table management. 
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A GUIDE TO SYSTEMS DEVELOPMENT 
JOHN M. GRILLOS 
AMERICAN MANAGEMENT SYSTEMS, INC. 


INTRODUCTION 


Developing a large scale computer application is an expensive effort, 
requiring careful, planned coordination of many different activities to be 
successful. This paper outlines the overall approach and key activities 
essential to the orderly development of a large system. 


Not all management problems require computer-based solutions; careful 
analysis can sometimes yield significant improvements simply through new 
policies or procedures. However, if the problem is regular and recurring, 
involves large amounts of data, or requires special monitoring and control, 
automation should be considered. 


This paper segments the development of a new system into three major 
phases: 


-- System Concept (Phase I) 
-- System Design (Phase IT) 
-- System Implementation (Phase III) 


These phases reflect the idea that development is a learning and refining 
Process, in which a few good ideas are expanded and detailed as more infor- 
mation becomes available to the point where millions of orderly pulses 
racing around in a computer perform the few functions intended when the 
development process began. 


Good planning is essential to the whole process. Each project requires 
a carefully designed plan, giving consideration to task dependencies, avail- 


able resources, non-system constraints, and management requirements. The 
guidelines presented here are a starting point for a task plan and a measure 
of task completion and project status. The iilestones defined in this 

paper are usually accomplished regardless of the size of the system. 
However, smaller systems quite often allow collapsing of two phases or sub- 
phases of development. These are individual considerations which go into 
developing a plan. 
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Good documentation standards are also critical to the development 
process. Each project task must be documented. Documentation reduces 
potential confusion in verbal communication, broadens exposure to and 
makes explicit decisions, and allows measurement of successful completion 
of most non-programming tasks. This paper gives an indication of the type 
of information to document. Other areas in which standards are useful 
include: Naming conventions for data elements, segments, files, data bases, 
data glossary, and so on; Programming techniques for structure, frequency 
of comments, and naming of COBOL paragraphs; Formatting for reports, 
forms layouts and so on; and Environmental considerations such as operating 
Standards, turnover standards, programming languages, use of data base, and 
sO on. 





A procedure for review and revision of all task documentation by both 
technical project management and concerned users should be in place. This 
is Supplemented by substantive Progress briefings periodically delivered 
to management. Disagreements and misunderstandings which persist through 
system development because of poor review procedures are very expensive to 
resolve in an operational system. 


Beyond the process and ideas above are the following considerations 
which are also keys to the total success of a system development. 


1. Personnel Assignments -- Beyond quality of people assigned 
is their orientation and training. Generally, business 
analysis skills are most useful in doing concept and general 
design work, and of course technically qualified professionals 
dominate staffing of detail design and implementation phases 
-- with business types once again involved in training and 
installation. However, involvement of technical talent in 
early project phases can head off problems caused by bad 
technical assumptions upon which important application 
functions may depend. Involvement of bus iness-oriented 
personnel in late stages of development provides project 
continuity and, thereby, insures that user requirements 
Stated during General Design are faithfully adhered to in 
Subsequent project phases. 


2. User Involvement -- System projects have little hope of achiev- 
ing intended benefits without adequate user involvement. 

Users must be the primary definers of system functionality, 

and must be involved in critical review Processes that occur 
at points throughout the development cycle. These requirements 
mean two things -- users must be actively interested in the 
project so that they are willing to spend the time to Stay 
involved, and project Planning must deal explicitly with user 
level of effort and timing considerations so that users can 
schedule project involvement into their routines. 
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3. Budgeting Process -- With good planning it is reasonable to expect 
reliable cost estimates for one phase beyond the current phase 
(e.g., reliable Detail Design costs can be prepared at the end of 
General Design). However, budgeting for an entire development 
cycle in advance or budgeting two phases into the future cannot 
be done with much reliability. Vagaries in staff productivity 
or costs, need to do tasks not foreseen in plans, personne] 
turnover, and a variety of other unforeseen problems seem to 
always overtake project cost estimates. Since full project 
budgets cannot be made accurately in advance, two things should 
be done -- budget estimates should be revised after each phase 
for management go/no-go decision making, and projects should not 
be hamstrung by attempted enforcement of premature and inadequate 
budgets. Such enforcement can result in no system or a system 
which does not meet important project objectives. 


The following discussion breaks each development phase into several 
types of tasks. Those tasks that would be repeated during the same phase 
for each of several subsystems comprising a larger overall system are 
indicated by an asterisk (*), 


PHASE I -- SYSTEM CONCEPT 


The purpose of the System Concept is to analyze a problem, define its 
Cause, and create an economic solution, which may utilize the computer. The 
emphasis iS on economic feasibility, but technical considerations are 
recognized in order to analyze the cost of any solution. However, these 
considerations are only examined in enough detail to derive rough measures. 
This phase is the first pass at a complete design. 


A. Define Scope and Effort 


The first task is to make estimates of the level of effort to be 
expended in examining the problem. A plan must be developed scheduling 
the tasks described in the remainder of this section. 


B. Review of Current System 


The current system should be examined to provide a base line against 
which the value of a new system can be measured. The current system 
includes all manual and computer systems considered for change. Some 
necessary information to be documented includes a description of process- 
ing, inputs, outputs, processing volumes, personnel utilization, computer 
utilization, and costs. 
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User review of all documentation should be done. Documentation should 
be reviewed quickly, yet in detail. The outputs and functions defined here 
Provide the base line for measurement and minimum requirments of any new 
system. 


Gs Determine Analysis Areas 


Based on the above review, several key areas usually stand out as 
being points where additional analysis is critical for system success. 
These "leverage points" may have any of the following characteristics to 
distinguish them from other potential concerns: 


1. High Volume Processes -- where small improvement can yield high 
return. 


2. Simple Clerical Tasks -- are usually easy to mechanize. 


3. Timelines and Quality of Input Data -- the cost of processing 
bad data for correction is usually excessive. 


4. Cash Management Benefit -- earlier billing and later payment 
have measurable savings. 


9. Timelines of Reports -- untimely reports usually force a 
secondary system to be created for control. 


6. Reduction of Codes -- several codes used to define the same 
characteristic are very frustrating to users. 


7. Management Interest -- any point where a concern has been 
specially expressed should be analyzed. 


D. Analysis 


Analysis is the key step. The areas defined in the previous task 
are -investigated in detail and alternatives for providing the required 
service in an efficient manner are considered. Analysis content will 
vary widely from project to project, and the process must be documented. 
The goal is to define a feasible solution which is economically superior 
to the present system and other alternatives. Each alternative must be 
described in functional terms, stressing the comparison with the present 
system and other alternatives. The cost of operating the system once it 
is in place and operating must be determined. The level of detai] should 
not be too great; if the economic feasibility of an alternative is so 
marginal that it hinges on a very detailed analysis, the alternative should 
be avoided. All benefits should be quantified if possible. Personnel 
reductions, cash flow, and inventory reductions are obvious examples. 
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Reports can be evaluated in terms of the action that could be taken if 
the information were available. However, it is usually best not to 
attempt to quantify their value. Any future benefit possibilities should 
be assigned an expected value. Cost avoidance should also be quantified 
and stressed. 


EF. New System Concept 


The results of the analysis areas are integrated into a new total 
system concept which also incorporates the definition and analysis of 
common system components which serve the entire system, such as report 
generators or data bases which were not explicitly considered before. 
Other elements of the concept are a system flowchart, narrative descrip- 
tion which emphasizes the flow of data and processing of major exceptions, 
a list of features, a list of remaining issues and criteria for resolving 
them, and a system operating cost/benefit summary. 


F. Phase II Task List 


The next task is to create a task list for the design of the system. 
Depending upon the size of the project, the task list may include General 
Design or both General and Detail Design. The task list includes the 
amount of resources required for completion. 


G. System Development Cost and Schedule 


Development cost for the second phase is derived from the task list 
by assigning a cost to the resources required. In order to estimate the 
cost of later phases, an estimating procedure based on the number of major 
files, programs, reports and forms can be used. Table 1 shows some plan- 
ning factors which may be adjusted by experience to the personnel actually 
involved. The resources required for Phases III3 and IIIC can only be 
estimated by personnel familiar with the user's environment. 


Since the system is very sketchy at this time, the number of files, 
programs, reports and forms -may not be accurately estimated. To correlate 
the costs developed this way, Table 2 can be used as a rough measure. If 
results generated from Table 1 differ greatly, well-defined reasons should 
be required. 
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TABLE 1 


Development Cost Estimation 
(Man-Days) 


Reports 1/ 
Major Minor and Project— 
Programs Programs Management 


General ; : 
Design Task List Expansion _ 
Detailed 

Design 


Programming 
and Unit 
Test 


To correlate the estimate generated from the "bottom up" approach, 
the following guidelines can be used as indicators of distribution of 





cost between phases. 


TABLE 2 


5% 
5% 
5% 











Phase IIIA 3 
Phase IIIB ] 
Phase IIIC 1 





V/V Project Management is calculated as a percent of man-days on other 
tasks. As the size of the project grows above 20-25 personnel 
assigned, extra management above this may also be required. 
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Schedule should be defined at this time. The development sequence of 
each subsystem including precedences and implementation priorities can be 
illustrated by a staging chart. A required implementation date, a limit on 
the maximum personnel assigned to a project, or a known team are possible 
constraints to the schedule. The goal is a rough schedule for initial 
planning purposes. 


Finally, return on investment or other financial viability measures 
Should be computed using quantified system benefits, operating costs and 
development cost schedule. 


H. Management Presentation 


As stated earlier, user involvement and management review is critical. 
The review at the end of the system concept is the key to beginning the 
actual design project. 


PHASE II -- SYSTEM DESIGN 


The goal of the design phase is to devise the most effective and 
efficient means to provide the services which were earlier defined as 
economically desirable. Where the System Concept analyzed economic 
feasibility within wide limits of technical capacity, the System Design 
phase analyzes technical feasibility of alternative methods to provide 
the desirable features. If the project is large, the design phase is 
broken into two subphases: General and Detailed Design. 


A. General Design (Phase ITA) 


The General Design phase is user oriented. All user issues should be 
resolved. Manual interfaces and processes, code types to be used and 
reporting needs are defined. The end product of the General Design is 
a specification of user requirements and interfaces, and a defined solu- 
tion to the major technical problems of the system. The technical 
feasibility of the design must be thoroughly analyzed and alternative 
technical approaches devised and evaluated. The following tasks are 
usually required: 
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1. Planning 


The task list from System Concept must be expanded into a work- 
ing plan for this phase. Personnel must be matched to tasks, tasks grouped 
and assigned for effective continuity, and task interdependencies consider- 
ed. Since integration of the subsystems is a primary goal of General Design, 
Significant time must be reserved for analysts to review each other's 
work. Review procedures for both users and technical analysts should be 
Precisely defined here, as well as procedures for resolving stalemates. 


2. Issue Analysis 


The issues to be resolved were defined in the System Concept 
phase. This analysis is quantified as much as possible, though these 
issues are generally harder to assign dollar values. A mechanism for 
resolving issues must be defined. Usually, a specific person is desig- 
nated to approve issue resolutions. It is also critical to impose 
and document deadlines for issue resolution. 


*3. Define Inputs and Outputs 


The problem of which functions must be defined first (input, 
Output or process) continually arises. It is often a restatement of the 
"chicken or the egg" riddle. The key here is to pick a sequence, and 
proceed with efficient timely analysis. In general though, a firm 
grasp of user reporting needs serves as a good starting point. 


Codes to be used in the system must be defined as the design 
progresses. This task is completely overlapped with file design, and 
is also sometimes a major issue. There must be some explicit addressing 
of the use and purpose of each major code. 





Report definitions should include: narrative descriptions, 
contents, purpose, users, frequency, and media. Files (both computer 
and manual) must be adequately described, including: 


€ Type of file. 


- System Master Files. Most of the subsystems 
use these files, though they are normally built 
and maintained in a separate subsystem. Designers 
of master file subsystems are often key personnel 
who insure system integration and finalize code 
definition. Master file definition is especially 
difficult to schedule since master file require- 
ments may change several times during the design 
Stage because of issues arising in processing 
subsystem design or technical problems which 
surface during the design. 
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- Subsystem Master Files. Used totally within a 
Single subsystem; and contain relatively stable 
information to be updated and maintained by the 
subsystem. 


- Input Files. Information from other subsystems 
is defined by the subsystem requiring the informa- 
tion, except, of course, at the initial entry of 
a source document. 


@ Description of files. 
- Description of Use. Narrative format. 


~ Data Elements. Description, rough size estimate 
and frequency. 


- Records. Grouping of elements. 


- Processing Intent. A description of what the 
file is used for and how it is to be processed 
(e.g., direct or sequential). 


- Organization. Definition of how the file may be 
organized, e.g., IMAGE, KSAM. 


Input documents must be described. The level of detail varies 
with importance to the system, and the system operating environment. 
Critical input documents should be roughed out and approved by the user. 
Occasionally, field testing is required, but usually critical documents 
should not be finalized in this phase. : 


Communciations requirements should be defined. Aspects to be 
considered and documented include rough estimates of line loading, loca- 
tion and types of terminals, transmission rates, recovery feasibility, 
fall back procedures, and alternative approaches. 


*4. Computer Processing 


Computer processing is described in terms of subsystem functions, 
not programs. The division of these functions into programs does not 
take place until Detail Design. 


Subsystem flowchart definitions describe process functions con- 
necting inputs and outputs. The functions are simply logical groupings of 
data manipulation, and definition of these is the key talent of a system 
designer. 
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Function definitions are detailed narrative descriptions of what 
each function will do. This does not mean a decision block level of flow- 
chart or description. It must be in terms understandable to a non- 
technical system user. 


Computer resource estimates based on the frequency of processing 
cycle and a profile of the inputs should be made. If technical feasibility 
of any alternative appears uncertain as a result of this analysis, further 
refinement by the use of simulation, emulation or more detailed analysis 
may be required. Establishment of technical feasibility is a requirement 
of this stage. 


*5. Manual Procedures 


Manual procedures related to system function should be documented. 
A processing flowchart should be prepared depicting operations to be per- 
formed and organizations which will handle inputs and Outputs. Detailed 
narrative descriptions should be used to describe coding information on 
forms, balancing needs, error correction, data entry and verification or 
validation. Personnel requirements over daily and monthly cycles, including 
profiles of activity over time (peaks and averages) should be defined. 


6. Environmental Conditions (System Configuration) 


The tasks in this area are concerned with technical support for 
the development and operation of the system. 


e Software Environment -- or system support utilities as 
well as more general installation support is analyzed here. 
Alternatives must be considered when differences in cost 
Or maintainability exist. Objects of analysis may include: 
data base approach, use of a report generator, inquiry 
facilities, use of a test data generator, and programming 
languages. 


® Training -- of programmers and analysts for later develop- 
ment phases should be planned and begun, if possible. 


@ Hardware Environment Analysis -- should be performed at 
the end of the General Design since it requires evaluation 
of all subsystems. If alternative hardware is under con- 
Sideration, system resources or needs must be analyzed, 
Including on-line storage, CPU utilization, (total hours 
required per processing cycle), I/0 elapsed time, order 
lead time, and communications support needs. 
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7. System Flowchart 


This is a key ouput from the phase. It should be understand- 
able to both user and computer personnel, and provide an interface for 
discussion purposes. Two levels should be produced. A summary level 
chart reworks the Phase I flowchart, with the same features, issues, 
descriptions, etc. An integrated detail chart links subsystem flowcharts 
and is used to check for integration. All detail subsystem charts are 
included on this consolidated version. 


8. Cost Benefit 


This 1s reworking of operating cost and benefits in light of 
new detail to insure continued economic feasibility. 


9. Phase IIB Task List 


A detailed task list and resource estimate is now required. 
This task list may still be in terms of process functions rather than 
detail components, depending upon staffing uncertainties, start date 
for next phase, etc. If so, the list will be expanded early in Detailed 
Design, as discussed later. 


10. Priorities for Development and Implementation 


This is a refinement of the initial discussions with user groups, 
and must be reviewed with them. Precedences may be clearer and costs of 
partial implementation can now be considered. Priorities may not indicate 
a rigid scheduling procedure, due to alternative distributions of project 
resources (e.g., if one subsystem can only use four analysts and six are 
available, then a second subsystem can be worked on). Priorities act as 
guidelines in assigning scarce resources to the project. Some factors 
to consider are extra bridge (or conversion) programs, revision to high 
priority programs when the full system is in place, early realization of 
benefits and progress visibility. 


11. Development Cost and Schedule 


The development cost can now be re-evaluated with the detailed 
Phase IIB task list. A further refinement of Phase III costs is also 
possible since a firmer estimate of computer programs is possible. A 
rough schedule must also be defined utilizing the priorities and pre- 
cedences known. 


12. Management Review 


The management review process has only to cover changes in scope, 
technique or benefits from the Phase I presentation. A progress report 
may be all that is required if changes are minimal. However, technical 
feasibility must be firmly established at this stage and should not be 
in doubt upon management review. 


B. Detailed Design (Phase IIB) 


The Detailed Design phase of a systems development project develops 
System specifications in sufficient detail to accomplish the programming 
and implementation tasks. If the system is small, then separating the 
design into two sub-phases may not be necessary. In any case the outputs 
Should be the same. If the implementation plan places development 
priorities on the various subsystems, the higher priority subsystems 
should have their designs completed before the lower priority subsystems. 


In this phase, process functions are grouped into programs, and 
detailed specifications are developed for these programs. Rough report 
formats are developed into report layout specifications, and all reports, 
including activity lists, are specified. Input forms are finalized. 

File contents are refined to detailed file specifications, and layouts are 
prepared for all files. Manual procedures are further detailed to the 
level of detailed job specifications. 


Non-application activites of this phase include making final arrage- 
ments to insure the availability of hardware and software (including 
communications facilities) to provide a testing and implemention environ- 
ment. Also, a series of final volumes are prepared which serve as the 
System documentation for implementation and later maintenance. 


The key aspect of Phase IIB then is a further refinement of design 
and planning work done up to this point. 


The level of detail required for a detailed program specification 
is determined by two things: 


-- The level of qualification of the programmers who will have 
to program from these specifications; the more senior, the 
less detail required. 


-- The staff continuity between Phase II and III. That is, if 
the same people who are designing the subsystem will also be 
programming the subsystem there is a reduced need for detail. 


The following sections discuss the items to be accomplished during 
Detailed Design. 


1. Detailed Project Plan 
A detailed project plan must be prepared to control the 
Detailed Design Phase. This plan is based on the task list prepared 
at the end of Phase IIA, and reflects the priorities of subsystem 
development. 
2. Resolve Remaining Issues 


There will surely be some issues remaining from Phase IIA. These 


should receive the highest priority for resolution before proceeding, and 
be settled very rapidly. 
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3. Codes 


It is necessary to define what new codes will represent. Con- 
Sideration may have to be given to alternative coding types (structured 
codes and random coding values), specifying the length and composition 
of each alternative. Give consideration to the integration of new codes; 
that is, if a similar code is used elsewhere in the same business, try 
to maintain a consistency of the structure, and assigned values. 


4. Detail Data Base Design 


Although this section is primarily devoted to considerations 
of a data base system, some of the concepts are useful and should be 
considered even when not ina "formal" data base system: 


8 Produce a glossary of terms for data elements for the pro- 
ject. This glossary will be constantly maintained through- 
out the project (and possibly throughout the use of the 
facility). It should include the element name, a description, 
its "picture", the source of the element, (eventually) which 
files it is in, and where its (subsystem) maintenance respon- 
sibility lies. 


@ For large projects, data base design is a further (but not 
final) refinement of the concepts and data needs studied 
in Phase IIA, and includes developing an overall data base 
design, examining data relationships both inside and outside 
the project, and developing initial data base size estimates. 
Consideration should be given to redundancy and efficiency 
tradeoffs and integration with other system DB requirements. 
Size estimates should attempt to deal with overhead storage 
for system flags and pointers. 


@ The final data base design is done later in Phase IIB, 
and should include finalized physical and logical layouts 
of the data base, access methods, estimates of the frequency 
and timings for backing-up, recovery, and reorganizing the 
data base, and an outline of recovery procedures. 


@ If necessary, select SYSGEN options to optimize the perform- 
ance of the data base facility for your project or system. 
TOTAL has relatively few SYSGEN options, whereas IMS has 
many. 


*5. Detailed Subsystem Flowchart 


The starting point for all detailed design work is a detailed 
Subsystem flowchart, showing all inputs, programs, files, reports and 
other outputs of the subsystem, and how they connect. There must be 
firm agreement between technical staff and the users regarding this sub- 
System flowchart before proceeding with Detailed Design. 


*6.  Inputs/Outputs 


For each subsystem, the inputs and outputs must be fully speci- 
fied in detail -- this includes reports, files (data bases), and input 
(source) documents. Each of these are treated below: 


® Reports must be specified in detail. Such things as a 
detailed report layout (with descriptions of the contents 
of each field on the report), a general description of 
the contents and purpose of each report, an estimate of 
the volume and frequency of generation, output medium, 
and special code values (e.g., error codes) should be 
indicated in detail. 


@ File specifications (layouts) consist of at least the 
details of the data elements and their groupings (e.g., 
COBOL-like layout or data base layout). The data element 
lengths, type relative positions, and frequency (of 
Specific groupings or record types) should be given, 
along with record lengths and blocking factors. 





@ Input (source) document formats should be finalized at this 
point. Besides form layouts, keying formats, revised 
volume and timing estimates, and a chart which cross-checks 
the data elements with the source documents to insure that 
all data required is being captured should be prepared. 


8 Communications steps include revising volume estimates, 
and other data, determining detailed back-up and recovery 
procedures, and, if there are dedicated facilities, de- 
tailing the entire communications network (lines, their 
locations, line type, conditioning, maximum transmission 
rates, modem requirements, multiplexing facilities, and 
any other data communciations control equipment requirements ) . 
A detailed cost analysis should be performed on this plan- 
ned network, if not already done. 
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*7. Computer Processing 


The initial task plan for Phase IIB which was prepared at the 
end of Phase IIA was process function oriented. However, the system is 
really program oriented. The relationships between these process func- 
tions and the programs to be specified have been given in #5 above. Now, 
detailed program specifications must be prepared, including: 


@ The program name, program identification, subsystem, inputs, 
and outputs. 


Q A brief description of the purpose of each program. 


@ Frequency of running and the estimated "stand-alone" run 
time. 


@ Recovery in the event of an external malfunction. 


@ A detailed program specification and corresponding detailed 
description should be prepared. As noted previously, the 
level of detail is primarily determined by the skills of 
intended implementors. Flowcharts will serve as the 
principal documentation of the programs for maintenance 
purpose. Therefore, accuracy is vital. A written 
narrative should be keyed to each box on each flowchart 
to elaborate on the meaning of that step. 


*8. Manual Procedures 


The need to have clear, workable manual procedures at the design 
stage cannot be overemphasized. General ideas of the manual procedures 
have been specified during Phase IIA, but these must be reviewed and 
detailed at this time. These procedures must be thoroughly reviewed and 
approved by the users. If possible, field tests of these procedures should 
be accomplished before their finalization. 


9. Environmental Conditions 


Technical support and planning must be provided in the software 
and hardware areas to insure that the necessary facilities are available 
for implementation of the system. 


® software support must be provided as indicated below: 


- Software decisions made in Phase IIA (e.g., data 
base management systems, reporting packages, etc.) 
must be reviewed and finalized. If they are no 
longer adequate, specific alternatives must be 
analyzed and recommendations made. 


- The software to support testing and implementation 
must be purchased and made available. The detailed 
implementation plan should be a guide as to 
when the various pieces of software must be available. 
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- Basic technical support must be provided to the 
implementation, e.g., test data generators, 
Standard error handling routines, program generators, 
data dictionaries, or special purpose routines. 
Because these utilities need to be available prior 
to programming, their development or installation 
should be started as soon as possible to insure that 
they are available when needed. 


= Test plans for the system software should be evolved 
and executed. 


- A detailed training program should be developed for 
the programmers, which would include familiarization 
not only with the new software systems (e.g., data 
base management systems), but also with the use of 
the software support utilities being developed. 


Hardware support must also be provided as follows: 


- The system resource requirements must be redone with 
the availability of the detailed design, and the CPU 
utilization, channel requirements, disks, tapes, 
terminals, and communications needs must be detailed. 
An order or modification of previous orders must be 
made. The delivery of hardware should be in phase 
with the needs for a testing, then an implementation 
environment. 


- Detailed plans for the physical facilities for the 
hardware (e.g., electricity, air conditioning, floor 
Space, false flooring) must be mace. 


10. System Flowchart 


Final subsystem documentation must be tied together to provide 
for easy availability for programming and maintenance. The items to be 


prepared are: 


A detail flowchart at the individual program level must 

be prepared for the entire system. This should be a con- 
bination of the flowcharts for the individual subsystem as 
done in #5 above. This flowchart should be backed up by 

a descriptive narrative, and supporting tables of programs 
and files. This flowchart is also very useful in ascertain- 
ing whether all subsystems interfaces are covered. 
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Final subsystem volumes (one per subsystem) should be pre- 
pared at the end of Phase IIB. These will serve as the 
final documentation for the subsystem, and should be a 
compendium of all files, programs, reports, and procedures 
previously prepared. Any later changes made during pro- 
gramming and conversion should be reflected in these 
volumes so that they can also be used to support mainten- 
ance. 7 


11. System Implementation Project Plan Task List 


A detailed task list must be prepared to cover the programming, 
systems testing, and conversion and training phases of the system 
development. The items to be covered in this plan are acceptance and 
performance criteria, coding and unit testing tasks, a detailed plan 
for program and system testing, and implementation phasing. 


12. Management Review 
A system overview presentation should be made to higher-level 


management and the users at the end of Phase IIB to gain specific approval 
to proceed to Phase III. | 


PHASE. III- SYSTEM IMPLEMENTATION 


Phases I and II accomplish the key tasks of definition and detailed 
specification of system scope, functions, and components. Phase III 
proceeds with these specifications to develop an integrated system of 
computer programs and manual procedures which is ready for installation 
in a production environment. 


System Implementation consists of programming and unit testing, 
system testing, and conversion and training. 


A. Phase IIIA -- Programming and Unit Testing 


During this phase, detailed program specifications are analyzed, and 
individual programs are coded, compiled and tested. 


1. Revise the Project Plan and Specify Detail Personnel Allocations 
and Work Schedules 
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2. Familiarize Programming Personnel with the Project 


To ensure smooth project continuity, it is important to instruct 
programmers on system functions and components before they begin detailed 
coding. This is done by having them review detail specifications including 
relevant charts, file layouts and functional narratives, and then having 
Programmers attend any formal training sessions planned for in Phase IIB 
(e.g., data base training courses). 


*3. Program Coding 


Detailed program specifications must be interpreted and translated 
into computer programs. 


Review detail program specifications. 


Where necessary, elaborate on program specifications in order 
to transform them into the working documents needed for 
program coding. At this point, it is useful to analyze 

input files, output files, processes, detailed calculations, 
and error conditions for correctness, consistency and 
potential use in program testing. 


Produce and compile program source code. 


Develop a plan for testing individual programs. 


*4. Unit Testing 


Individual computer programs are tested to insure that they meet 
program specifications. 


Install and checkout unit test software. This software, 
including utilities and aids to facilitate program testing, 
was defined and specified during system design. 


Generate unit test data. Files needed for program testing 

can be produced by both programmers, who generate files for 
a single program and a central technical support staff which 
creates system test master files used by groups of programs. 


Test programs and revise where necessary. 


Evaluate initial test volumes and timings in relation to 
the estimates developed during system design. 


Review unit test results and certify programs as ready for 
system testing. 
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B. Phase IIIB -- System Testing 


Phase IIIA produces individual working computer programs which meet 
detail program specifications. System testing ensures that these pro- 
grams and manual procedures operate together in the integrated manner 
necessary to accomplish system functions. 


ae 


se 


#4. 


Develop system acceptance criteria and test plan. The test plan 
normally covers such areas as input data to be used, expected 
outputs, interaction between computer system and manual pro- 
cedures, system acceptance criteria, test plans for logical 
group programs, and a plan for phased, integrated system test. 


Install system test software. These programs including utilities 
and aids to facilitate system testing were defined and specified 
during system design. 


Generate necessary input, master and intermediate system test 
data files. 


Conduct system test and revise programs where necessary. 


@ Analyze known inputs, resultant outputs, and the interaction 
between computer programs and manual procedures. 


@ Compare system test volumes and timings with benchmarks 


developed during system design and unit testing. 


@ Update system and programming documentation. 


@ Review system test in relation to system acceptance criteria, 
and obtain user approval for final implementation. 


Ce Phase ITIC -- Conversion and Training 


Ls 


Conversion 


@ Complete systems, operations and user documentation. 


8 Convert required master and systems files. 


0 Conduct pilot test as the first step of the phased system 


implementation plan. Steps include completing training 
of user personnel, installing any necessary pilot hardware 
of software, running the pilot test as a parallel run 
against an existing system (if applicable). and evaluating 
the pilot test in light of systems acceptance criteria. 

If necessary, revise programs, procedures, documentation 
and manuals based on results of the pilot run. 
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Obtain system acceptance and begin full scale system 
implementation. 


Final implementation and signoff. 


2. Training 


Develop a plan for training users, operations personnel 
and systems maintenance personnel. 


Conduct training sessions for users, operations personnel 
and systems maintenance personnel. 
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DECISION TABLES - AN EFFECTIVE PROGRAMMING TOOL 
DANIEL F. LANGENWALTER 
INTEGRATED SUSINESS SYSTEMS, INC. 


Manufacturing businesses have many information processing 
problems such as the rules for ordering materials, the 
rules for granting credit, the logic of what to build to 
meet a customers requirements, the rules for union dues, 
deductions for savings and pension plans, tax requirements, 
etc. 


Decision Tables have been used to express the logic in a 
manner which people can understand and also can be used 

as a computer program. Both General Electric and B. F. 

Goodrich Chemical have reported a three-to-one increase 

in programming productivity when using Decision Tables. 

Here are some examples of applications which illustrate 

the power and simplicity of Decision Tables. 


Turbine blades are up to five feet long and must be ma- 
chined to airfoil shapes. A FORTRAN program produced the 
magnetic tape necessary to control the Excello contour 
milling machines. Unfortunately, some bug caused the 
milling cutter to gouge a blade once in a while. 


The decision was made to do the program over using Decision 
Tables along with calculations. The analysis and tables 
were completed in five weeks. The subroutines were com- 
pleted in two more weeks. The program was independently 
checked and debugged in three weeks and has been running 
successfully for ten years. The people involved say that 
this success in solving a difficult logical problem is due 
to the use of Decision Tables. 


We started using Decision Tables when we were challenged 
to automate an entire business. 
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The business chosen for this work built electric indicating 
instruments for industrial panels. These included D.C. volt- 
meters and ammeters and AC voltmeters, ammeters, wattmeters, 
frequency meters and power factor meters. To get a bill of 
materials for each instrument we decided to use Decision 
Taples to generate the bills. One of the Decision Tables 

is like TABLE 1000 - ARMATURE ASSEMBLY, Figure 1, next page. 
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The Decision Tables expressed very complex product logic. 
As a result we were able to generate the bill of materials 
for any one of several million instruments. The cost of 
storing and processing bills of material was reduced by 

10 to 1. We proceeded to try using Decision Tables on 
many other product lines and found considerable success 
if: 


1. The product was made up of a variety of parts and 
assemblies used in different combinations. 


2. There was a large variety of final products. 


The work of capturing the logic would not be justified for 
a simple product line or for a single one-of-a-kind product. 


After this success in the order entry - bill of materials 
application, we looked at the manufacturing instructions 
for making parts and inspection. 


A business making industrial controls made extensive use 
of Decision Tables to convert a panel layout into the 
factory instructions for shearing, punching, and bending 
Sheet metal. The enclosure design was captured in TABLE 
2100 - BACK DIMENSION and TABLE 3010 - HOLE SPACING - VS 
on next page, Figure 2. 


The system required a very large amount of logic for bend 

allowances, tool designation, etc. The logic was done in 

Decision Tables and then programmed. This system has been 
up and running successfully for over ten years. 
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2100 TABLE - BACK DIMENSIONS 

2110C MATERIAL BACK BACK FLANGE MTG  ASSI" 
2120C ENCLOSURE HEIGHT THICK WIDTH HEIGHT WIDTH HOLE HOLE 
2130 PH g& PH # M=& BHe & BH= & Bas & BBE & BGs 
2140 GE 10.00 &LT 28.00 # 0,090 & PN-0.16 & PH-O.J6 & 1,36 8 1,11 & 3,42 
2150 28,00 &LE 56.00 # 0.120 & PH-0.25 & PH-0.25 & 1.42 & 1,07 & 3,38 
2160 -- & -# --8 o@% Gat Soe =e & 
2110 ENDT 

2120 PRINT: ERROR IN ENCLOSURE HEIGHT 


3010 TABLE - HOLE SPACING - VS 
5020C NUMBER 
5030C ENCLOSURE HEIGHT OF HOLES 
5040 Pi =6©& «©PHCO# «COBDS Ff 


5050 GE 10.00 aLT 15.00 # 2 # 
5060 15.00% 31.00% 3 #F 
5070 31.90% 45,.00# 4 # 
53080 45,00 &LE 56.00% 5 # 


5100 ENDT 


FIGURE 2, 


& GOTO # 
& 3010 # 
& 3010 # 
& 2120 # 


In a computer business, the quality control people had 

set up a punched card system for recording the type of 
defect on a circuit board, but found that manual analysis 
of the data required extensive time and had many errors. 
They used Decision Tables like TABLE 4100 - OPERATOR ERROR, 
Figure 3, next page. 


Their comments were that the program runs and is easily 
expandable, if necessary. 


Thus, we have a number of cases where complex logic was 
expressed in Decision Tables and used to control a computer. 


In several businesses as diverse as an insurance company, 
a construction company and a builder of nuclear power plants, 
payroll and labor cost analysis logic has been done in Deci- 
Sion Tables. One such table selects the correct tax table 
depending on marital status (M=married; S=Single), and pay 
requency. 

WK = weekly 

BW = bi-weekly 

SM = semi monthly 

MN = monthly 


TABLE 2880 - MARITAL STATUS, PAY FREQUENCY, Figure 4, shows 
the Decision Table. 


The single monthly federal tax table would be like TABLE 
4380 - SINGLE MONTHLY FEDERAL TAX, Figure 5., where: 


FED is the federal withholding tax 
TXGR is the taxable gross income 


FE is the number of exemptions 
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4100 TABLE - OPERATOR ERROR 


4110C DEFECT 


4120C CODE TYPE OF OPERATOR ERROR 


4130 DEFC # ND & NE= 
4140 EQ 26 # ND+1 & = -- 
4150 «8329 # -- & NEF 
4160 50 # 6 --& -- 
4170 4O0# --& -- 
4180 ENDT 


&@ MF= @ NG= & NX= & GOTO # 
& -- & -- & NX+1 & 4200 # 
g -- & -- & NX] & 4200 # 
&@ NF+l & -- & NXt+1 & 4220 # 
& -- & NG+1& NX+1 & 4200 # 


FIGURE 3, 


8° LL-9 


2880 TABLE - MARITAL STATUS, PAY FREQUENCY 
23890C MARITAL PAY 
2900C STATUS FREQ 


2910 MST & PF # GOTO # 
2920 EQM 8 & WK # 3010 # 
2950 M & BW # 3180 # 
2900 M & SM # 3320 # 
2950 M & MN # 3510 # 
29600 S & WK # 3770 # 
2970 S & BH # 4020 # 
2980 S & SM # 4200 # 
2990 S$ & MN # 4370 # 
5000 ENDT 


FIGuRE 4, 


6°LL-9 


4370 FINC=IXGR-62,50*FE 

4380 TABLE - SINGLE MONTHLY FEDERAL TAX 
4390C FEDERAL 
4UQOC TAXABLE 
4410C INCOME 


4420 
41130 
4440 
4450 
4460 


4470 


4430 
4490 
4500 


LE 


FINC 
142,00 
329.00 
621,00 
783.00 
954,00 

1288 ,00 
1533.00 


4510 ENDT ~ 
4520 FED=(FINC-DAMT) *PRCT+BT 


— I — Ee TS TR 


BASE DEDUCT 

TAX AMOUNT 
Bl= & ODAMT=  & 
0.008 90,00 & 
0.00 &8 142.00 & 
29,92 & 329,90 & 
82.48 & 621,00 & 
119,22 & /88,00 & 
159,06 & 954,00 & 
252.58 & 1288.09 & 
332.58 & 1538,00 § 


Ficure 5, 


PRCT= 


0,90 
0,16 
0.138 
9.22 
0,24 
J.28 
Di OZ 
0, 56 


PERCENT- 
AGE 


“SR “Re ORR 


- 


Another problem is the different union deductions. A table 
can be written giving each deduction depending on the union 
involved, These tables show the logical relationship so 
clearly that changes are easy to make. 


The conclusion, from the twenty years of experience with 
Decision Tables, is that they are very useful in writing 
complex logical relationships. They are, in effect, a 
powerful programming language which is useful in many 
functions of a business. Several users have reported 

a doubling or tripling in the productivity of their 
programmers. 


Based on this experience, MUSCL - a Decision Table language 
was developed. The best ideas from five other languages 
were used, READ and WRITE commands for file processing 

and a REPORT writer to format reports, were included. 


MUSCL has been implemented on a Hewlett-Packard 3000 to do 
payroll, order entry, and executive compensation system. 
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Microprocessor Based Product Design on an HP3000 
a Presentation for the 
7th International Meeting of the 
HP General Systems Users Group 
Denver Colorado, November 1978 


by 
Jack C. Armstrong 
Los Altos Research Center 


Hardly a day passes without the announcement of a new product or new 
application based on micro-processors. Concurrent with these announce- 
ments are constantly reducing prices for microprocessor hardware. Un- 
fortunately, as applications become more complex, the cost of software 
development has soared. 


Microprocessor manufacturers were quick to respond to complaints about 
the high cost of developing products around their devices, by introduc- 
ing microprocessor development systems. These systems, which were 
valuable in debugging both software and hardware, were immediately 
placed into wide-spread use. Not unreasonably, microprocessor vendors 
offered development systems tailored very specifically to their own 
products, which as a not-coincidental side effect locked their customers 
into using their chips to the inclusion of other vendors. This effect 
increased as the cost of the development systems increased. Recently, a 
few development systems have been introduced (not by microprocessor 
vendors!) which accommodate several manufacturers lines, but these sys- 
tems often lack features available in the vendor’s custom systems. 


Another response to the need for software development aids was the 
development of so-called “cross software", which allowed the use of a 
larger, or at least CIEFETENE, computer to compose and assemble/compile 
programs for microprocessors. This software was made available on all 
major commercial time sharing services, and organizations with in-house 
computer systems purchased cross assemblers and cross compilers for use 
on their own machines. The trend towards cross software has been 
accelerated by the rapid acceptance of higher level programming 
languages with the need for larger compilers. The use of another 
machine for software development has much to recommend it, including 
freedom to choose from many different microprocessors at minimal in- 
cremental expense, use of a common, and usually better, text-editor, 
etc. The snag in this process comes when the software is written and 
compiled without syntax errors...now comes actual debugging of the pro- 
gram logic. This, in addition to check-out of the prototype hardware, 
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generally requires transferring the software to a microprocessor devel- 
opment system, with its capabilities for in circuit emulation, hardware 
break-points, single stepping thru instructions, etc. 


Using the cross software approach frequently means a cost Savings in the 
purchase of development systems, both because fewer of them will be 
necessary, and the less sophisticated models (without text editors, 
assemblers, compilers, etc.) may be used. However, it is rare that 
development systems of some sort will not be required. 


One company which found themselves involved in developing a product 
around a microprocessor chose to stand back and look at the entire 
process of developing the product, and all that that entailed.- This 
was Scientific Micro Systems, of Mountain View, California. The 
following steps were identified in the complete project of developing, 
testing, and supporting a new microprocessor based product: 


1. System specification and functional descriptions. 
2. Detail design specifications. 


3. System implementation, (hardware and software), including con- 
struction of prototypes, coding software, etc. 


4. System test and evaluation. 


5 System documentation, including technical reference manuals, 
user’s guides, manufacturing instructions, sales literature, etc. 


6. Product support and maintenance. 


The system which evolved at SMS utilized an HP3000, several micro- 
processor development systems, and a prom burner, all integrated in one 
system for the development of a microprocessor based product. The 
total system involved the use of a sophisticated text editor and word 
processing system (LARC EDITOR/SCRIBE) which included features designed 
to aid program development, documentation, _and tracking changes in both 
source programs and associated literature. Cross assemblers and cross 
compilers were implemented on the same system, which produced object 
code files on the system disc. These files were then "down loaded" onto 
either the microprocessor development system (for testing) or onto a 
prom burner to fuse proms for the completed system. 


As consultants to SMS, we developed two programs, one for interfacing to 
the development system, and the other to interface directly to a prom 
burner. These devices were plugged into HP3000 RS232 terminal ports, 
and interface programs written in SPL. Once developed, the interface 
programs were not terribly complex, but the thought and design took 
considerable effort. 
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Two approaches were considered in attaching the development system to 
the HP3000. The first would be to connect an RS232 port on the develop- 
ment system to a terminal port on the HP3000. This would require soft- 
ware in the development system which would allow a user on the develop- 
ment system console to talk "through" the development system to the 
HP3000, which would then be tricked into thinking that the development 
system is a user terminal. A user could then log onto the HP3000 and 
run software to access the object files created by the cross software 
and transmit then back to the development system. At SMS, the develop- 
ment system being used had its entire operating system in firmware, so 
no modification was possible. Instead, we chose to fool the development 
system rather than the HP3000. This was done by connecting the develop- 
ment system console line to a dedicated terminal port on the HP3000. 
Users may utilize any terminal to log onto the HP3000, and then run an 
interface program which reads the terminal, looks for a few special 
commands, and otherwise sends any line typed directly to the development 
system. The special commands cause disc files (of object code) to he 
transmitted as though they were being entered by hand directly into the 
development system. Thus, the development system thinks it is talking 
to a user console, not an HP3000. (A user who always types at 240 
characters per second!). 


In other, more flexible development systems, either technique could be 
used, and each have some advantages. In the case of the prom burner, we 
again made the device think it was attached to a terminal, not a com- 
puter. This program is actually more complex than the interface to the 
development system, as the prom burner may be both read or written, and 
we incorporated a facility to compare two blocks of object code, compute 
check sums, fill unused addresses with a user selectable constant, etc. 
Also, the program must deal with proms of several different sizes and 
types. 


The success of this installation led to another company acquiring an 
HP3000 for similar purposes. Caere Corporation, also of Mountain View 
California, interfaced not only development systems, but single board 
computers (SBCs) to terminal ports on their HP3000. The SBCs actually 
have very simple operating systems in firmware which allow down loading 
via an RS232 port, so programs on the HP3000 can load and run test pro- 
grams on prototype devices, which then transmit back test results for 
later analysis on the larger machine. They are using the same text 
editor and word processing system as SMS, and for similar purposes. 
They also use cross software, but have a rather unique twist to their 
use of a development system. One high level microprocessor language 
currently has a more efficient compiler implemented as a resident com- 
piler on the development system than those available as cross compilers 
on larger systems. Caere intends to use the HP3000 for text editing and 
compostion of source programs, but will then ship the source to the 
development system for compilation!. The resulting object code will 
then be transferred back to the HP3000’s disc, for subsequent down load- 
ing onto SBC’s connected to other ports. Thus, the development system 
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becomes a "compiling box", and rarely if ever will be used for anything 
else. 


The advantages of directly interfacing to microprocessor devices, via 
Standard RS232 interfaces, are that each component of the complete 
system is doing whatever it is best at, with a maximum of flexibility 
for future changes. The major improvement in this scheme would be to 
upgrade the cross compilers available. Ideally, one should be able to 
chose from several high level languages to develop software with, and 
then select the optimum microprocessor for the application. This 
selection would be considerably aided by a choice of code emitters all 
working off the same compiler, so code density and instruction counts 
could be compared. Finally, a direct interface to a development system 
would allow final testing of the competed system. The HP3000 has proven 
to be an ideal nucleus for such a total system, and most of the software 
is available today. 


1 NDermott, Jim, "Experts Tell How to Hold Down the High Cost of 


Microprocessor Programs", Electronic Design 26, vol. 23, (Dec. 20, 1975) 
pp20-26. 


Bursky, Dave, "It’s Getting Easier to Program Microprocessors With 


the New Software Design Aids", Electronic Design 2, vol. 25, (Jan. 18, 
1977) pp20-26. 


Snigier, Paul, "Microprocessor Development Systems - Which One is 
“Best’", EDN, vol. 27, no. 5, (Mar. 5, 1977) pp68-78. 
Nauful, Eli S., "Software Support for Microprocessors Poses New 


Degign Choices", Computer Design, vol. 15, no. 10, (Oct. 1976) pp93-98. 
Ivie, Evan Le, "The Programmer’s Workbench -- A Machine for 
software Development", Communications of the ACM vol. 20, no. 10, (Oct. 
1977) pp746~753. 
Auclair, Dan, "A Minicomputer-Based Microprocessor Development 


System", Compcon 78 Spring, 168 IEEE Computer Society International 
Conference, pp334-337. 


Rochkind, M. J., "The Source Code Control System", IEEE 
Transactions on Software Engineering, SE-l1, 4 (Dec. 1975) pp 364-369. 
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PRESENTATION TITLE: UT200 RJE Subsystem 
INDIVIDUAL (S) NAME(S) : Donald Klett 


ADDRESS : Sangamon State University 
Springfield, Illinois 62708 


ABSTRACT: 


A 200 User Terminal (UT200) simulator has been developed for the HP3000 
Series II that supports remote job entry service to large Control Data 


Computer systems. The design and implementation of the subsystem will be 
presented. Input/output options and the user interface will also be 
discussed. 
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HP 3000/IBM 1403 COUPLING EXTENDS SYSTEM UTILIZATION 
RAY LORENZ 
SPUR PRODUCTS COPR. 


The HP series 33 gives the user the option of a 180- 
characters-per-second or 400-lines-per-minute dot matrix 
printer. Series II and III give choices of solid-character 
printers with speeds of 300, 600 or 1250 lines per minute. 
Being solid character printers they have advantages over 
dot matrix printers. However, all three are drum printers 
which lack operating features and options inherent in chain 
or train printers. 


In fact, a chain or train printer can greatly expand the 
utilization of any data processing system compared with a 
drum printer. For example, an operator using a chain or train 
printer can quickly interchange character sets, and even in- 
dividual characters, so that a number of fonts (even custom- 
designed type faces), special symbols, numbers and letters 
can be selected. Furthermore, printing quality is greatly 
improved, a factor that also makes it usable for some func- 
tions not desirable for a drum printer. 


Spur Products Corp. has developed a controller that 
makes an IBM 1403 printer plug-compatible with the series II 
and III computers. (Figure 1) It replaces any of the three 
drum printers offered by H.P. The IBM 1403-2, or -3 or -Nl 
can be driven. Rated print speed of the -3 and -N1 is 1100 
lines per minute, and that of the -2 is 600 lines per minute. 
Of the five models of 1403 printers available, we selected 
these three for use with the HP 3000 because they have 132 
print positions. 


The 1403-series printer was selected for this marriage 
because it can correctly be called the best item of electro- 
mechanical equipment ever produced. As such, dependability 
and versatility also are among its attributes. 


A comparson of the operating features can best be under- 
stood by comparing the mechanical features of the drum and 
the chain or train printer: 


In the drum printer a cylinder rotating at constant 
speed has a complete set of printing characters embossed 
around it at each print position. Hammers strike the desired 
characters as they rotate into print position. (Figure 2) 
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While a limited selection of fonts on the drum is avail- 
able from the manufacturer, the drums cannot normally be 
changed by the operator. Furthermore, individual characters 
cannot be changed under any conditions. This not only com- 
pletely takes away an option available with train or chain 
printers, but makes it necessary to replace the entire drum 
if a single letter is worn or broken. 


Furthermore, no drum printer has been able to time the 
impact on the rotating drum at the precise moment that the 
character is in position. The result is that printed lines 
are wavy across the page. The HP printers, which actually 
are made by Dataproducts, are not as bad as some in this 
regard, but they also will go out of adjustment. Wavy lines 
discourage the use of the printer for sales solicitation 
letters or most printed communications that reach the public. 
Printed communications are often the Only media on which the 
company is judged, so they should have the highest quality 
possible. It is natural that the 1403 is the standard of the 
direct marketing industry. 


In such applications two other characteristics of the 
1403 are definite economic advantages: 


1. Paper is slewed from the bottom of one form to the 
beginning of the next at approximately 80 inches per second. 


2. A vertical format unit can enable the paper to be 
advanced to any pre-selected position, such as slewing from 
the bottom of one form to the top of the next. The carriage 
control commands are punched into a paper forms control tape 
built into the printer. 


In a chain ortrain printer an array of character slugs 
moves horizontally at constant speed past a set of hammers-- 
one hammer for each print position. In chain printers the 
Slugs are connected and pull each other around a track. [In 
train printers the slugs are not connected and push each 
other around the track. (Figure 3) The model 1403-2 uses 
a chain and the 1403-3 and 1403-Nl use trains. 


Our respect for the 1403-series printer is so great that 
we chose it as the printer to be driven by the Spur con- 
troller even though it has two marketing disadvantages for 
us: 


1. It has been out of production since 1970. There 
still are hundreds of thousands around, but the market ob- 
viously is not growing, and any manufacturer likes a growing 
market. 


2. Model 1403 printers cost as much as $30,000, which 
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is only about $8,000 less than it cost when it was new. Its 
cost per printed line is about the same as the latest model 
IBM printer. Still, you have to wait at least three months 
for delivery of a reconditioned 1403 that may be 20 years 
old. 


Whenever there is an unusual computer printing job it 
invariably is done with a 1403. One company uses it to print 
on mylar for labeling products stored outdoors. The Atomic 
Energy Commission uses it to print its Nuclear Science 
Abstracts because it has the print quality-that allows the 
copy to be read after it is reduced photographically and 
printed by offset lithography. Both the AEC and Stanford 
Research Institute use it because special chemical and math- 
ematical symbols can quickly be added to the print train. SRI 
even creates Greek and other foreign letters by overprinting 
standard characters. In all of these applications, inciden- 
tally, the IBM 1403 printer is used with a computer other 
than an IBM. 


The Spur controller is software-compatible with pro- 
grams supporting the HP 3000 series IIT or Iif. To accomp- 
lish this while making it possible to permit the operator 
guickly to interchange character sets it was necessary to 
incorporate a memory in the controller that makes the for- 
matting adjustments necessary for each type train. 


A random access memory enables the operator to table 
load the memory. To make reprogramming as easy as possible 
when a single character is changed, the Spur controller mem- 
ory has positions for 240 characters. Each has a direct 
relationship to the 240 character positions on the train 
(normally 48 characters repeated five times around the track 
for speed in aligning the chracter with the print position). 


Optionally, the program can be permanently stored at the 
factory in programmable read-only memories. When this option 
is selected three PROMs are included with the controller, one 
for each of three print trains selected by the user. A front- 
panel switch enables the operator to change the program when 
the train is changed. Any number of additional PROMs can be 
ordered for as many trains as the user plans to use. 


Naturally if PROMs are requested the operator is re- 
lieved of the problem of programming, but does not have the 
option of changing the computer language at a later date, 
which would be possible with table loading. 


Even without considering the increased use of the sys- 
tem made possible, costs of a 1403 printer and Spur con- 
troller system are competitive with similar HP equipment. An 

HP 2618A printer with a speed of 1250 lpm has a list price of 
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$35,400, and the HP controller adds $1,275 to the total 
price. An IBM 1403-Nl printer costs somewhere between $20,000 
and $30,000 and the Spur controller costs $17,500: 


When comparing costs it is important to recognize that 
an increase in utility affects the comparable economics. If, 
for example, sales letters now can be printed with a 1403 
printer while they previously could not and had to be sent to 
a service bureau, the comparative costs would have to be re- 
done, especially if the additional printing job can be done 
when the computer otherwise would be idle. 


CONCLUSION 


Just as it can truthfully be said that the HP 3000 "ends 
the computer compromise," so the Spur controller ends the 
printer compromise. In some ways the printer is the most 
critical part of the data processing system. It produces the 
final product of the system. Therefore, its printing quality 
is the standard by which some unsympathetic boss, not to men- 
tion the public, may judge your entire effort. And most im- 
portant, the printer can be a limiting factor in the variety 
of jobs that can be done. For these reasons some operators 
of HP 3000 general systems have welcomed this new product, 
and many more are expected to join them. 
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PRESENTATION TITLE: A Real-Time Instrument Interface System for the HP3000 
INDIVIDUAL (S) NAME(S): Gordon R. Symonds 


ADDRESS: Environmental Health Centre 
_Tunneys Pasture, Ottawa, Ontario 


ABSTRACT : 


A real-time, terminal-oriented interface which permits acquisition of data 

from laboratory instruments and other real-time devices is described. The 
terminal/interface system can be used with any device having a serial ASCII 
output port, either RS232 or 20 ma current loop. It performs control functions, 
baud rate conversion, etc; in addition to serving as a normal session mode 
terminal. Current applications include automatic thermoluminescent dosimeter 
(TLD) readers, blood analysis equipment and an animal weighing system. 


The system has been used in production for over one year, and has proven to 


be a low cost, easy-to-use solution to interfacing instrumentation to the 
HP3000. 


H~095.01 


DISK © 
‘SUBSYSTEMS 
SOFTWARE 


CONSIDERATIONS 


H-@7.1 


“Foreign trade" enhances the quality of life of any 
nation. In similar fashion, “foreign devices" attached to a 
computer's central processor unit (CPU) can often enhance the 
performance and cost effectiveness of the computer installa- 


tion. 


In both cases, protectionist attitudes can limit the 
potential benefits. In the world of computers, the first in- 
stinct of the user is to protect his system software. The con- 
cern is legitimate. Investment in software can easily exceed 


the value of computer hardware. 


System software has been designed, in most cases, to oper- 
ate within the context of a specific hardware configuration. 
Even minor alterations in the hardware characteristics can have 
far-reaching and often unpredictable effects on the operating 


software. 


Yet the fact is that nearly every computer installation is 
limited not by the capabilities of its CPU, but by the throughput 
and capacity of the input/output and mass-storage devices attached 


to the CPU. The performance of nearly every computer installation 
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can be enhanced, therefore, by taking advantage of state-of-the- 


art advances in the design of these peripheral elements. 


But this is acceptable only if the new equipment is "trans- 
parent" to the existing softward. Neither the CPU (for tech- 
Nical reasons) nor the user (for emotional reasons) should be 
disturbed by the switch to a new type of I/O or mass-storage 


device. 


software Transparency 


These comments apply to any type of equipment attached to 
a computer--including terminals, printers, tape transports, 


data=communication lines, and disks. 


This paper will concentrate, however, on disk drives-—-for 
several reasons. Disks represent the most eccnomical method 
for providing fast-access mass storage. Moreover, since disks 
are usually treated as an extension of main memory, they are 
intimately linked to the CPU and its operating softward. And 
if these facts were not enough to give pause, disk technology 
has been progressing at a very rapid rate during the past few 


years. 


- The challenge, then, is to realize the potential of the new 
technology (e.g., the new 3330 and Winchester drives) and still 


remain "software transparent." Techniques must be found to 
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attach an advanced (but "foreign") drive, without altering a 
single instruction in the operating system software or appli- 


cation programs. 


Three different methods have been developed to accomplish 


this objective: 


a) Fixed plug-compatibility 
b) Dynamic plug-compatibility 


c) Virtual transparency 


As one of the industry's leading suppliers of disk systems 
for computer enhancement, CalComp uses all three techniques for 
achieving software transparency. Each method has its place -- 
depending on the type of system and the volatility of the hard- 


ware and software. 


Fixed Plug-Compatibility 


The original technique was fixed plug-compatibility--dating 
back to the 1960's. It was, in fact, the basis for the first 
effective penetration by independent disk Suppliers, such as 


CalComp, into the monolithic IBM marketplace. 


Small but significant changes in the mechanical design of 
disk drives provided major improvements in reliability and ease 


of maintenance--plus a modest increase in system throughput. 
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Despite these advantages, however, the new products could not 
have found a market unless they appeared (to the CPU) to be 
identical to equivalent products offered by IBM. 


The "foreign" drives were provided with cables that could 
be plugged directly into the IBM mainframe. They also had 
electronic logic circuits that could respond, with absolute 


fidelity, to IBM's disk-drive commands. 


But the fixed nature of the interface was a severe handi- 
cap. Independent disc suppliers were inhibited from developing 
performance characteristics beyond those that could be controllea 
by the IBM disk protocol. They would be, by definition, "trans- 
parent"--and of no practical value. Suppliers had to wait for 
TBM to make the improvements, and were therefore in a constant 


state of catch-up. 


Of mich greater concern was the fact that IBM could, at any 
time, make minor changes in its own operating software. These 
could render, overnight, all "foreign" disks ineperative. Some- 
times the changes could be anticipated and allowances méde in 
the control circuitry. Just as often, the only solution was an 


emergency retrofit of existing units in the field. 


Despite these difficulties, the cost savings and performance 


benefits were sufficient to create a viable plug-compatibie 
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market for independent disk suppliers. Their sales grew at an 
accelerating pace and soon extended beyond IBM to systems pro- 
duced by other mainframe and minicomputer manufacturers. But 
the vulnerability to change has remained as a constant threat 


to both users and suppliers. 


Dynamic Plug Compatibility 


One solution to this problem is what can be referred to as 
dynamic plug-compatibility. This is the capability of "mapping" 
or making one type of disk look like another type which is 


recognized by the host system. 


two factors have contributed to the development of this 
concept. Of major importance, of course, has been the intro- 
duction of LSI. and microprocessor circuitry. A microprocessor 
can be readily adapted to the type of control functions required 
in a disk interface. Equally important has been the expanding 
role of mass storage facilities as the principal method for 
enhancing the efficiency and throughput of computer installa- 
tions. Disk storage facilities, taking advantage of new, high- 
Capacity drives, have grown to the billion-byte level--as a 


starting point. 


In addition to size, there is also a new emphasis on variety. 
Disk facilities may include drives with removable or non-removable 
media with fixed or moving heads. Small-capacity units may be 


added for private files, while maximum-capacity units serve as 
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basic storage to provide a minimum average cost per byte. 
The configuration of the facility may, in fact, change from 


month to month, or even hour to hour. 


With the new emphasis on size and capacity, the additional 
cost of a dynamic, microprocessor-based disk interface can be 
easily justified. And as an added bonus, the interface can be 
easily altered to meet any changes in the disk hardware or 


Operating system software. 


The functions of a dynamic plug-compatible interface are 
dictated by the microprocessor program--stored in easily inter- 
changed PROMs or floppy disks attached directly to the interface 
controller. Or the operating system itself can define its own 
plug-compatibility by downloading a suitable interface program 
at the time of system generation. Response to changes can be, 


for all practical purposes, instantaneous. 


Virtual Transparency 


Fixed plug-compatibility is still the most direct method 
for achieving software transparency in applications where the 
system software is static and little advantage can be gained by 
changing the mass storage facilities. Dynamic plug-compatibility 
can be justified when the storage facilities are large, or when 
there is a high degree of volatility in the system software and 


physical makeup of the storage facility. 
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In both of these cases, an assumption is made that the 
“plug-compatible" device is recognized by the existing system 
software. But this leaves a third situation in which neither 
technique is truly applicable. For example, the system software 
may have been written without any provision for the newer types 
of disk drives (e.g., 300 MB drives with a 1.2 MB/second trans- 
fer rate). There is, therefore, no “plug” to be compatible 
with. Situations could also exist in which the hardware and 
software are evolving at a rapid rate, yet the scope of the 
mass storage facility cannot justify the use of a dynamic, micro- 


processor-based "mapping" approach. 


In both of these instances, a technique which can be referred 
to as "virtual transparency" can be an effective solution. CalComp 
is using this method to interface a variety of different capacity 
Trident disk drives to CPU's produced by many different mini- 
computer manufacturers, some offering many distinctly different 
operating systems. All of this is accomplished, moreover, with 
a microprocessor-based disk-controller design--produced in volume 
and thoroushly tested by hundreds of successful applications in 


the field. 


A Logical Answer 


Virtual transparency can best be understood in terms of its 


origin: Virtual memory. Originated by IBM and now adopted by 
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most minicomputer and mainframe operating systems, virtual 
memory was developed as a way to free programmers from any 
need to allocate and keep track of the computer's memory 
resources. Application programs could be written in abstract 
terms. The computer's operating system would translate 
"logical" virtual-memory addresses into physical addresses-- 


taking advantage of any memory space available. 


As programs grew in size and larger volumes of infermation 
were processed, much of the data (including application programs 
and portions of the operating system itself) were transferred 
to mass-storage devices like magnetic tapes and disks. But 
these were treated as I/O peripherals, and soon the computers 
were spending a majority of their time on the transfer of files 


between mass-storage and memory. 


The virtual-memory concept again came to the rescue. Just 
as the use of logical addresses, independent of physical locé- 
tions, simplified the life of the programmer, an extension of 
the virtual memory technique to mass storage devices served to 
relieve the main operating software from an equivalent concern 
for the physical configuration of the system. Subsidiary 
modules could accomplish the necessary mapping and address 


translations. 


The benefits are manifold. The programmer and his applica- 


tion program can ask for data stored at a logical location. The 


executive portion of the operating system passes the request 
along to the appropriate memory-management module. The subsid- 
lary software determines whether the requested data is in main 
memory~-immediately accessible to the application program--or 
is remotely stored on disk or tape. If the latter is the case, 
the transfer can be initiated by the lower-level software while 
the operating-system executive negee on to other, more demand- 


ing tasks. 
Device Handler 


The first step in the transfer operation would be for the 
memory~management module to pass the physical address along to 
an even more subsidiary software unit: the device handler for 
a specific disk-drive controller. Only now,.three steps re- 
moved from the application program and two steps removed from 
the main body of the operating-system software, would the ad- 
dress request take a form that relates to a specific, physical 


device. 


Virtual transparency takes advantage of the fact that there 
are, in truth, two interfaces between the disk storage and the 
system software. One is the physical interface at the plug con- 
necting the disk-drive controller with the CPU hardware. The 
second is the software transition between the virtual addresses 
of the system software and the physical location of the stored 


data. 
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Either one of the interfaces can be used to maintain 
“software transparency." The plug-ccompatible techniques use 
the physical interface. CalComp's virtual-transparency method 
takes advantage of the modular structure of nearly all operat- 
ing systems. When the memory-management module "calls" for a 
specific device-handler module, it can just as easily invoke 
a CalComp-supplied segment of software as one supplied by the 
computer manufacturer. In neither case is the main body of 
the system software affected. Not a single line of the exist- 
ing application programming must be changed. Yet the user has 
the advantage of the latest technology disks, with capacities 
that far exceed those of the largest disks anticipated by the 


designers of the original software. 


System Generation 


The simplicity of the virtual-transparency concept is 
evident each time the operator "generates" the computer system 
for a specific group of application programs. The complete set 
of operating-system modules is rarely used. Instead, to con- 
serve main-memory space, the operator invokes a system-genera- 
tion program that allows him to specify only the modules required 


for the particular applications. 


A CalComp-supplied module is included in his choice of 
options. The software itself is supplied on tape or disk, depend- 


ing on the system configuration. The operator also has a sheet 
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of load instructions, written in exactly the same format as 
that used by the computer manufacturer. at an appropriate time 
in the system-generation procedure, the operator loads the 
CalComp device-handler module--or leaves it out. Moreover, if 
there is ever a problem with the CalComp disk hardware or soft- 
ware, the disk-controller cable can be Simply unplugged and the 


system regenerated without the CalComp module. 


Summary 


The true test of "transparency" is whether a foreign device 
can be added to a computer system to enhance its performance and 
capabilities without affecting, in any way, the user's investment 
and confidence in his operating software and application program- 


ming. 


At least three different methods can be used to achieve this 
result. CalComp has used all three techniques to enhance hath 


existirg and new computer installations. 
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ORGANIZING A LOCAL GROUP OF COMPUTER USERS 


Douglas J. Mecham 
Hughes Aircraft Company, Ground Systems Group 
P.O. Box 3310, Fullerton, California 92634 


Abstract 


This presentation concerns itself with the organization, development, and 
management of local/regional user groups in support of communication 
among computer system users. Additionally, considerations for the 
relationship among RUGs, with the HP General Systems Users Group, and 
with Hewlett-Packard is also presented. The objective of a local users 
group is to promote the active interchange of ideas, techniques, and soft- 
ware among the users. This interchange can take place with only two 
people. The topics discussed below are some ideas that may be used to 
promote the success of users in a local group. 


A Simple Approach 


Undoubtedly you have one or more friends that you confer with regarding 
your computer system problems. If you and your computer friends have 
met over lunch to discuss a computer technique you have the beginnings 
of a local users group. Most likely you will return to work with a new 
piece of software or computer technique to try out. Let us identify the 
basic aspects of such a users' meeting: 


Meeting Arrangements--one of the group called the others and invited them 
to join him for lunch. 

Meeting Opening--The objective of getting together was, in some fashion, 
Stated and any new persons were introduced. 

Technical Discussion--One of the group explained how he had solved a 
System problem and discussed associated software used. As the 
discussion progressed questions were asked and comments made by 
the others in the group. During the discussion reproduced copies of 
the software listing were handed to the group. 

Computer Products--Since each day a new product for the computer 
market is introduced, one of the group discussed his research of the 
new product that may be useful to the others. 

Social Hour--After all the involved technical material the group relaxed 
over coffee. 

Next Time--Because members of this group had several other computer 
problems they decided to meet again to share more information. 


As you can tell by the description a local users group meeting took place-- 
simply and easily. 
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Needless to say with more and more users becoming involved with HP 
systems such a small meeting could rapidly grow. The basic meeting 
elements will not change but a little more planning and organizing is re- 
quired. A meeting of computer users need not constitute an official group; 
but it is useful to have a spokesman to convene the group and communi- 
cate with the larger users group. The following paragraphs present the 
considerations involved in organizing a group of local computer users. 


Orientation 


The object of such a computer users meeting is to share one's own know- 
ledge and experiences of computer systems with others who may not yet 
understand the system. This, of course, provides self-esteem, a key 
psychological requirement in a group. Also, such sharing certainly 
provokes others to share their knowledge and experiences. Additionally 
the presentation of two items of information often times results in a 
synthesis providing a third and different item of information. For 
example, development of a file handling routine by one user may be put 
with another user's indexing routine to form a data management module. 
Through the users meeting, a user may discover a simple solution during 
a brief discussion with another user that he had been battling with for a 
week. 


The collective of computer users can often provide the resources necessary 
to solve a problem not easily solved by an individual. For instance, 
comparison of tests performed with different data communication equipment 
or under different situations may yield enough data to solve a difficult 
problem. Or, you may just need the ideas from several other users to 
formulate a solution to your problem. 


—»> [A users group does not make sense without user involvement] 


Likewise, individuals in the group may be able to contribute a mail listing 
program for distribution of mail to the group members. Economically, the 
formation of a group of users makes sense because software, an expensive 
item to develop, may be shared. An objective of a group may include one 
or more services such as publication and distribution of a newsletter and/or 
Maintenance of a software library. In particular, a formalized users group 
can often arrange for technical experts to make presentations to the 

group as well as sponsor training seminars. 


When a local group of users relates to a larger group such as RUGs to 
HPGSUG, it is important frequent communication take place between them. 
The larger group may be able to find solutions for users in your group 

who have problems. Certainly the larger group provides a larger base for 
sharing software. Such a relationship is a two way street, however, and 
contribution by your local group to the larger group is necessary. For 
instance, a local group could sponsor a technical session at an international 
meeting. By spreading such a work load the larger task is accomplished 
without over burdening any individual. 


Thus, the formal orientation of a group of users is any objective which, by 
definition, must meet their needs. Before describing the technical aspects of 
organizing a group of users consider the individual user who would 


make up such a group. 


The User 


The objective for most users of computer systems is to solve their 

problems and enhance their software/hardware to perform more efficiently 
With greater capability to do their job. The success of a users group is 
dependent upon understanding the memberuser's perspective; the perspec- 
tive is to solve his problem in a simple expedient fashion. If a users group 
Can meet this requirement both the user and the group will be a success. 


The contribution a user makes to a users group depends upon his partici- 
pation. Certainly a user's expertese and experience will allow him to 
participate easily in technical functions. For the inexperienced user 
participation may be in the areas of administration and support of the group 
functions, such as maintaining mailing lists. Together a users group can 
function. The inexperienced users will advance to the experienced levels, 
the experienced to more sophisticated problems, and new users will join at 
the inexperienced stage. As professionals we have an obligation to 
contribute; each user taking a small responsibility can produce a useful 
benefit for all users. 


The most important user attribute to pay attention to in a group is the user's 
attitude. Since most groups of users depend upon volunteers to keep the 
group active particular attention needs to be paid to keeping the atmosphere 
around the user's involvement positive and self-satisfying. The dedication 
of a user varies over a wide range as does his sensibilities. Recognizing 
these traits and managing them can be an asset. For the most part this 
involves common sense, responsiveness, common courtesy, being observant, 
and giving recognition. 


A user's expectation is easier to meet in a volunteer organization than in a 
commercial organization. In the former the user is usually intimately involved 
and the destiny of his expectations is a function of his own effort. In the 
latter the user always expects more when he is paying money and is not 
involved in the "product". 


Watch out for users who promise a great deal but contribute little. It is 
difficult to prevent users from taking advantage of a volunteer group for 
their own ends; on the other hand, there are most likely a few individuals 
who contribute a great deal. While it is impossible to satisfy the latter's 
desires or repay them, public recognition is most fulfilling. Psychological 
satisfaction is often an important and satisfying reward. 


—— [Apathy is the worse enemy of a volunteer group. 
Enthusiasm is a group's greatest asset. ] 


Who should be included? Too often with larger computer systems only the 
computer center specialists get involved. While they have an indepth 
enthusiasm the users at the terminals should not be overlooked. A special 
local users group program for clerical personnel who interface with the 
computer might help dispel "computer fears." The "upper" management who 
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must make key decisions regarding your system might be interested in a 
limited involvement to better educate themselves in the way of the computer 
system as well as meet other managers making similar decisions. 


Now that some awareness of individual users has been brought out and 
objectives made clear where does one start to organize a group of computer 
users? 


Where/How to Start 


Why organize? It would be nice if the interface of all people just fit together 
to arrive at the desired goal. Since this is not the case in the real world 
Someone needs to plan the sequence of events to arrive at that goal. Any 
organization is predicated on an agreed-upon group objective. This may 
come about through an informal conversation with a few friends with a 
common product or application interest who decide to interface among them- 
selves in the future. The user interface may manifest itself through a 
meeting, newsletter, software library, or a combination of each. The user 
meeting is one of the easiest to start with since people like to socialize. The 
particular subject matter may be around a special interest such as word 
processing or a particular vendor product, or both. 


An effective method is to get a few "key" friends involved who you can count 
on to at least carry out an initial meeting of users. Make sure the communi- 
cations between the key group is free and easy since a time lag and a 
hinderance of communicatiions can postpone activity and dampen any 
enthusiasm. The next item of business is to establish communications with 
other users. 


A first meeting at your company or local hotel facilitates easy arrangements 
and control. By organizing the basic meeting aspects described in the 
Opening of this presentation your meeting will be a success. Depending upon 
how ambitious the key group is the meeting advertisement may be by word of 
mouth or a formal, mailed, invitation. 


——> [Frequent user meetings over lunch are easy and effective. ] 


If the meeting sparks some interest and a definable need to interface among 
users in the future exists then a more formal group may be organized; 
although, several meetings may take place prior to serious organization of a 
group. A key to a successful first meeting is to arrange for all attendees to 
return home a "winner," that is, make a contribution to the user's future 
Success. Such a "prize" may be a software program or inside information on 
a vendor's product. Before the first meeting has adjourned the next 
meeting or user interface mechanism needs to be planned and volunteers 
designated who will implement it, thus the next "key group" is formed. Note, 
if there are no volunteers either abort the group organization or be pre- 
pared to perform a GREAT deal of work. 


For the first meeting keep expenditures and meeting operations to a minimum. 
To offset any dollar costs collect a donation at the door. An alternative is to 
find a sponsor such as a product manufacturer or user company whose 
interests are served by such a meeting. Most likely both clerical assistance 
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and operations support, such as reproduction of notices and mailing, for 
the first meeting will come from the "key" group companies. Thereafter a 
more formal mechanism for funding and incentive for manpower needs to be 
found. Some ideas will be discussed later. 


User Education 


One of the most attractive elements of a users group is its capability to 
educate users. Informal education is done through user meetings and techni- 
cal publications; while this is rewarding the more organized/formal technical 
seminar is popular. Corporations seem to support the specific seminar since 
managers can easily relate specific seminar topics to their projects. Both 

the area of special application interest and computer system (or subsystem) 
product have their "gurus" who are willing to speak. The vendor usually 
has specialists who can present such a seminar. A users group could make 
the necessary arrangements while charging each attendee a required fee to 
pay the specialist for his preparation and any handouts. For example, a RUG 
on the West Coast sponsored a very successful seminar on HP3000 peripheral 
user maintenance given by Hewlett-Packard. This is a win-win seminar 

Since HP benefits from more knowledgeable users and users can solve their 
problems faster. Such a seminar is an easy success. 


Note that computer professions are hungry for computer knowledge. This 
need makes it easy for a users group to establish an educational objective. 
It just remains to focus in on a topic. 


Communications 


During the formation and subsequent operation of a users group the most 
important element is communication. If those in the key group do not relate 
their problems and successes then plans are difficult to make, let alone adhere 
to. Likewise constitutants of the group probably will not respond if they do-not 
receive some form of communication from the key group. In fact users who 
have contributed to the group who do not receive communication when 

expected can become bitter to the detriment of the group. If advice is 
requested in the communication then accepted when it is received individual 
cooperation is increased. 


—> [Communication is a terrific professional pacifier. ] 


Individual cooperation in a volunteer group is valuable; the greater the 
individual member communication the greater chance for group success. 


The information that must flow in a technical organization is tips, techniques, 
hints, kinks, along with meeting times and places. Communication needs to 
take place as often as necessary. This means if you communicate while you 
are thinking about it the link is made and progress can take the next step. 

A number of simple and easy acts of communication can build an effective 
network. 


—»> [Lack of effective communication has been the downfall of many groups. ] 
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Different requirements dictate different methods. For instance, the post 
Card or note is easy and quick especially if mailing labels are already printed. 
Letters are more formal but do show more thought for a professional 
approach and they serve as a good audit trail so-new ideas can build on past 
actions. A good secretary can make all the difference in the world in 
getting communication out. 


The newsletter of course is a more formal but easy way to communicate with 
a number of users. However, a newsletter requires a dedicated volunteer 
and considerable user contribution. Special publications are very useful 
since they are specific in nature and usually treat technical material in- 
depth. Such a publication results from the dedication of a very few users 
but unlike the periodic newsletter it is usually a one-time task. Both of 
these methods of communication can be very effective and simple to produce. 
These publications may, however, be quite formal and require a complex 
publishing operation. The most effective newsletter/publication is not 
necessarily the "slickest," easy and simple techniques for production of 
these items is found in the literature [1]. 


The telephone is quick and easy for most users. While it is difficult to 
communicate many details over the telephone this instrument is very effec- 
tive for directing a group of users by the key group and receiving status 
on activity. An automatic answering device can provide an easy method to 
communicate to the members and collect brief comments; such a device can 
be made available for communication 24 hours a day, unattended. 


If the espectations of member users are to be met then mechanisms for user 
feedback need to be devised. This may take the form of a questionnaire 

or telephone campaign. Keep in mind that talleying responses and perform- 
ing an analysis on the results may overwhelm the uninitiated; so keep 
responses very simple. Also, keep in mind that the number and accuracy 
of responses is directly related to the complexity of the questionnaire. 
Again, keep the questionnaire short and simple. It is better to have several 
short questionnaires than one long one. 


If your group warrants it, effective communication may be supported by 
clerical assistance; it is well worth hiring a professional secretary part time 
for typing tasks. Of course, micro computers, simple printers, and an 
elementary text editing program can serve well as a secretary (except for 
spelling). 


Handling the information flow and keeping it moving is important since 
newsletter editors thrive on new items and the key group needs the in- 
formation to formulate plans to support the group. A central address and 
desk is useful for this purpose. Information must be appropriately re- 
distributed in a timely fashion as well as just accepted. The formal infor- 
mation flow by mass mailings requires some serious thought. The key 
member responsible for such mailings needs to be aware of the considerable 
effort required to stuff, seal, address, stamp, and mail a large set of 
letters, not to mention printing. The cost of mailing can be optimized by 
planning the weight just below a postage price break and by using photo 
reduction techniques. 
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With the advent of word/text processing on micro computers the tasks of 
producing mailing labels, letters, etc. are easy. Even simple FORTRAN 
programs and simple text files on the HP3000 computer system can effectively 
Support these tasks. Multiple, personalized letters, can easily be printed. 
Also, computer data communications can be used most effectively to get 
users to contribute articles; it is easy for a computer system editor to "type" 
an article. For instance, many HP3000 computer installations have a 

terminal dial-up facility. Thus, a newsletter editor could dial up such a 
System and copy the contributor's text file to a terminal tape cartridge 

or printer for subsequent use in producing a newsletter. 


The local users group can perform a real service to its members by communi- 
cating with other local users groups and the international groups; the ~ 
communication is two ways. You might consider exchange of newsletters 

and notices as well as software. Good seminar speakers can also be found 
this way. 


The Users Meeting 


Computer users need to get together to discuss their successes and problems 
of their systems. In most instances a local group can have a very success- 
ful but simple meeting by considering the items discussed in the intro- 
duction of this presentation. Consider the aspects of a more organized 
meeting, although these aspects also apply to the small simple meeting 

where appropriate. 


There needs to be a central managing committee to insure consistency 

and follow-through before and after the users meeting. Be very aware of 
the effort required by each committee member; each member should commit 
themselves in a formal manner as a warantee on dedication to complete the 
Job. Make sure the meeting tasks are well defined and assigned. The 
magnitude of each task needs to be evaluated in light of the committment 
made by the committee member to perform it; the work effort is double 

that of any reasonable estimate. 


—> [Large meetings supported by weak committees 
can turn a meeting into chaos. ] 


Smaller informal user meetings can take place often at convenient times such 
as over lunch or in the evening. However, the larger full day meetings 
require planning a day when there is a minimum of conflicts with member 
users. Multiple day meetings should be avoided due to accommodation 
problems, competition for a member's time, and user saturation levels. The 
location of a meeting should be central to the group; however, special 
locations are attractive. Depending upon the budget and nature of the 
gathering meetings are easily arranged at hotels, schools, homes, or 
vendor facilities. The city to hold a users meeting is most likely obvious 
for a local group of users...except in Los Angeles. 


Economics are always difficult for local groups since "seed" money is 

often lacking; asking for pre-registration fees or vendor contributions can 
be helpful. Group projects to raise money are also helpful. The larger the 
meeting the more difficult to budget since all cost factors must be analyzed 
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and scrutinized since profit margins are very narrow. A simple meeting 
fee is to have each member contribute a fixed amount towards a single 
budget item such as a meal/refreshments. 


Since the computer field is expanding at a phenomenal rate there are a 
great number of resources for technical presentations. The simplest and 
easiest is the group membership; many computer professionals have a 
speciality topic he/she could discuss. The meeting committee can be very 
helpful in encouraging a user speaker and helping him prepare. Vendors 
of audio visual equipment often have booklets on making technical 
presentations. Vendors and universities are also two good sources for 
speakers. Keep in mind any audio visual support required by speakers. 

It is often enlightning and fun to have a special speaker during the meeting 
talk about a non-computer related topic; it relaxes the minds of the listeners. 
Be sure to recognize the speakers in some manner; a free meal ticket is 
usually easy while a speaker's gift is nice. In any case send a letter to 
each speaker before and after the meeting to give him meeting particulars 
and thank him. A key to a successful meeting is to give sufficient lead 
time for users to plan to come and speakers to prepare; plenty of mailings 
help. Each potential attendee should be made to feel that if he/she comes 
to the meeting they will return home a winner and a greater success. 


Proceedings and technical papers require a definite dedication on the part of 
a meeting committee. Remember each submittal needs to be edited and 
evaluated not to mention all the mechanics necessary to publish them. 

There are some techniques and guidelines, however, that make this choice 
easier. For local group meetings a simple Xerox reproduction or offset 
printing will suffice for handouts at the meeting. Attendees seem to like 
even the briefest of descriptions on paper. 


Vendors can often be a great source of support for a users meeting. They 
may even be willing to sponsor or underwire costs, refreshments, facilities,... 
provided they can display their wares. This approach works even on a 
small scale by contacting a vendor salesman. 


Don't forget to have some fun at user meetings by having a drawing for a 
"crazy" door prize. If funds permit a more serious door prize 

is good and/or a small gift for the meeting host, presented before the 
whole group. Kudos for all who contributed to and participated in the 
meeting is a necessity. Then, end the meeting on a high note with the 
attendees thinking about the next "great" meeting. 


Software Library 


All computer users like to get a hold of another user's software contribution 
but often does not have time to contribute himself. An easy rule for this 
situation is, tit-for-tat, only those who contribute have access to the 

other contributions. 


The form and format of a software contribution must be simple and easy 
but consistent so a user can easily compare, search for and retrieve 
entries. The quality of contributions is difficult to maintain but if the user 
has documented his source code well, and provided a working example and 
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a simple user's guide then the recipient should be delighted. Assuring 
quality is very time consuming but a minimum quality can be maintained 
if the thorough examples can easily be proven to work. 


Collection and distribution of software library entries needs serious 
thought. The media is the first consideration (floppy, paper tape, etc.), 
Organization of supplementary documentation second, and third (but most 
difficult) how to get the job of reproduction/distribution done. There are 
many approaches but the more the contributing user does in formatting and 
testing his contribution the easier collecting and organizing the software 
becomes. Indexing a software library is not easy but a permuted title 
index is one easy method, provided each title is meaningful. 


Managing and Administration 


For small local froups this aspect is relatively easy since the atmosphere 

is informal and activities are minimum. As the group grows a serious effort 
on the part of the leaders needs to be put towards the business aspects, 
l.e., the transition from a "club" to a "business" is considerable. Consider, 


1, How to best meet the needs and expectations of the users. 


2. Volunteerism and getting the tasks done. 


When computer professionals become involved and passionate towards a 
group they may tend to show emotion and be sensitive to: personal reactions. 
That is, leaders need to pay attention and be sensitive to personal politics 
enough to make most of the users successful most of’ the time. 


—>[Cater to active enthusiasts since they are 
the heart of a users group] 


Only volunteers who are responsive and serious about contributing can be 
asked to perform a task. The task requested to be completed must be 
well defined and feasible within the necessary time frame. Keep in mind 
that such a volunteer type task is probably low on the volunteer's 
priority list. Thus, be generous in designating a time frame but be 
definite about the required completion date. Make sure the volunteer 
knows when he is done, i.e., recognizes an end point. Do not be vague 
nor overwhelm the contributor if you wish the task completed. 


Unfortunately the family related to the enthusiastic professional may 

suffer and account should be taken of this fact. There needs to be some 
recognition or activity planned to involve them. An individual's contribution 
to the group can be adversely effected by his family and vice versa. 


Administration of a larger users group requires establishing well-defined 
objectives, a guideline for operation, and specification of particular 
services to users for particular costs. 

Vendor Interface 


If a users group is focussed on a particular vendor product such as the 
HP3000 computer system establishing an interface with the vendor is 
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important. Such a relationship is mutually beneficial since the vendor 
has an indepth knowledge about how his product works and a successful 
user assists in promoting vendor sales and provides valuable feedback for 
the vendor. 


It is important to recognize that a vendor company is made up of indivi- 
duals, each giving a different response to a users group. Recognize 

also that the vendor's priorities may not be the same as yours. A users 
group, however, can assist the vendor in clarifying items of common 
interest to users that merit priority consideration. Clearly a users group, 
as a group, could possibly provide alternative solutions. An example 
might be support of a user who maintains a particularly useful utility 
program. 


Since the vendor is in business to make a profit users group activities 

that promote sales are more easily supported by the vendor. Thus user 
meetings open to vendor sales prospects are a success. Successful 

vendor customers support sales and thus vendors tend to support software 
libraries and technical communication media such as journals. 


A good, friendly working relationship between the users group and the 
vendor is necessary if both are to be successful. Caution, however, 

only a minimum of requests should be made of the vendor; if the users 
group is a success the vendor should volunteer more than adequate support. 
If the users group remains independent from the vendor the group has 

a freedom needed by enthusiastic computer system users and the users 
group need only moderate eccentrics to keep progress in motion. 


Business Approach 


If a group of users can function as an informal group and accomplish their 
objectives then that is the easy and simple club approach. When the group 
erows to a state where a significant amount of organization is required, 
People are hired, and considerable money is processed. The club needs 

to become a business. 


This transformation is considerable and requires a business plan, legal 
status, financing, and the like. There is legal counsel available that 

will assist in such preparation. Of course, when a users group becomes 

a "business" the user services, operations, and resources, along with 

costs and expenses need to be well defined. The "official" users group 
needs to plan for carrying on each day, for a directorship to make decisions, 
and a plan for passing the group on to the future. At this level the users 
group must be run as a business and not the informal club if it is to be 

a success. 


Structure 
The more formal structure of a users group is not required unless it is 
needed. The need comes when the key group cannct administrate the group 


easily and/or it is necessary to form a consolidation of communication 
channels. For volunteer groups this threshold is very low. In a volunteer 
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group each subgroup can more easily complete a clear limited task. The 
sum of such efforts if coordinated well, can produce useful results. 


The subgroups formed may be around the group's operational tasks such as 
meetings and publications. Other subgroups may form around application 
areas, vendor products or geographical areas. The important point here is 
that each subgroup must have a specific task to perform with a definable 

end point; the subgroup must commit to accomplishing that task. Continual 
follow-up, encouragement, and assistance is required by users group manage- 
ment. If this effort cannot be put forth then just lists of committees are 

a burden and the subgroup should be dissolved. 


Conclusion 


Becoming involved in a users group is a learning experience. You must 
realize that while you will gain a great deal of information your rewards will 
never match your contributions. There is, however, a great latitude for 
Self satisfaction. The alternative to involvement is stagnation, an un- 
challenging position. If you do not belong to a group of users then join 
one or form your own, it is easy and simple. 
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KEYNOTE ADDRESS 


and 
SESSION REVIEWS 


Keynote address: "Future Possibilities--Hardware, Software and People". 
CPT Grace Murray Hopper, USN 


The outstanding event of the conference was a memorable keynote 
address by Captain Grace M. Hopper of the U S Navy. Before an audience 
of 500 conferees in the ballroom of the Denver Hilton, CPT Hopper gave 
a one hour and forty minute talk during which no one was seen leaving 
and a pin drop would have been clearly heard (except during the many 


applauses). 


The address is difficult to summarize because of its substantial 
content, but could possibly be best described as "an eyewitness account 
of the evolution of electronic computers, plus advice and predictions 
concerning their future". 

The entire speech was recorded on videotape by the Users Group and 


will soon be made available to members. Some highlights are: 


-- CPT Hopper’s involvement in the development of COBOL - the several 
deaths of COBOL, including a tombstone. 

-- The first computer "bug". 

-- Why we in the computer profession must begin considering the value 
of the information we’re processing rather than only its quantity 
or cost. 

-- What a nanosecond looks like. 

-- Why the future will be in distributed computer systems based on 


mini’s and micro’s rather than large centralized systems. 


Viewing a videotape of the address or seeing CPT Hopper in person 


is very highly recommended. 


-Bill Gates 


Note: Further information regarding the videotape will be forthcoming 
in an edition of the Newsletter. 


A 01 
COMPUTER AIDED INSTRUCTION 


Diane Christopherson of the University of Wisconin, River Falls discussed the work 
they have been doing to convert the Computer Aided Instruction package designed for 
HP 2000 for use on the HP 3000. After some comments of the difficulties they have had 
they she went into a full discussion of how the user takes advantage of the various 
features of the CAT program. 


Computer Aided Instruction is divided into three sections: The Instructional 
Dialogue Facility (IDF), the Math Drill and Practice section, and the Instructional 
Management Facility (IMF). 


Within the IDF the teacher can defien any lesson desired in almost any subject 
imaginable in any one of seven languages including Portugese, Swahili, and the other 
modern European languages. Also included in the language menu is Concise an 
abbreviated form of English. Lesson preparation does not required that the teacher 
know or understand a proranming language because the Author is led through the 
lesson preparation by a series of prompts which give a choice of selections such 
as the text to precede the lesson, questions to be asked and possible correct and 
incorrect answers with programmed responses to each. The teacher can insert a number 
of hints which the students may request as they progress through the lesson. The 
author can even insert a response for the unexpected answer. By specifying the 
number of tries the student may make on any given question the teacher can decide 
when the student has failed the lesson and needs to return to other review material 
before going forward with the lesson. For this purpose failure messages are prepared 
within each lesson. 


The correct and wrong answers can be specified within ranges as well as specific 
numeric or literal strings. Here again the programmed response can tell the student 
he is close to the right answer, give it another try. There is even a provision to 
accept a misspelled answer called the ‘don't care character’. 


As the student works through a program lesson he is permitted to branch to other 
functions, call up the calculator program for arithmetic steps, skip ahead in the 
lesson or back to a previous step. The author can specify how long the student is 
permitted to work on a geven question or lesson or may leave it open. In either 
case the computer gathers statistics on the students’ performance. These statistics 
when produced through the IMF aid in charting the students' progress and in determining 
the students' grades. 


It was estimated that the instructional lessons require about 15 hours of teacher 
preparation time per hour of student use but since the preparation only has to be done 
once and the students can use the programmed lesson for an indefinite time it does 
become an effective too. At any time after creating the lesson the author can go 
into n IDF function which permits changes in the questions, answers, repsonses or 
complete rearrangement of the sections or sequence of the lessons. 


The Math Drill and Practice is set up on two levels. M1 is designed as 6 grades 
of 24 blocks each. Each block is made up of a pretest, 5 lessons, and a final test. 
If the student scores a 100% on the pretest he is skipped ahead to the next lesson in 
the block. ‘The M2 level is designed for junior high or remedial senior high school 
math work up to the beginning level of algebra. 


In addition to the instructional programs above the CAI also has the IMF through 
which the student logs on and off the system, which keeps track of student records of 
participation and if you like school enrollment. It is this facility which prepares 
the reports as requested by the teacher or school administration. 

C. Mallette - Student 
Metropolitan State College 
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COMPUTER AIDED DESIGN 
Residential Energy Audit 


In view of the worsening oil shortage the work being done at the 
University of Wisconsin, River Falls, by Dr. N. H. Prochnow and his 
associates, to aid in evaluating home energy uses becomes more and more 
valid. With oil consumption mear an all time peak conservation of the 
energy we have is the only means of postponing the time of complete 
depletion of our resourses. Marlys Nelson described how, with the 
State Health and Energy agency the University is conducting surveys 
of low income housing and then bringing these homes up to an acceptable 
level for heat conservation purposes. 


Young people in the youth opportunity corps are used to take 
measurements of the building and report the data to a central location 
where it is entered into the computer and run through the analysis 
program. The program then prints an output with recommendations for 
upgrading, the approximate cost of the improvements and the amount 
that the improvement should save the home owner on his heating bill. 
This can be calculated on the basis of any one of nine feating fuels 
and their current retail prices. 


The data collected consists of building size, condition of walls, 
windows, ceilings, and roof, some calculated R values which the 
investigator can easily get from the tables in the guide, and the 
condition of the foundation walls. The style of building is also 
considered because the existence of basement, crawl space, and additional 
floors effects the heat loss patterns for the house. Using a degree 
day determined for the zone of the state the computer approximated the 
homeowner's heating bill which he can compare with what he has actually 
been paying to see if the computer's heat loss estimate is accurate. 


Since education of the young is the only way we can begin to train 
people to conserve what energy we have this program has also been 
extended to the 45 high schools who are connected with the University 
computer so that Social Issues classes, general math and general 
science classes can use it. In addition to teaching the conservation 
of energy and the related course material needed to collect the data 
it also begins to teach the student something about computer applications 
and has created interest in learning to program the computer as well. 


Cc. Mallette 
Student 
Metropolitan State College 
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Corporate Modeling 


Design and Implementation of 
Financial Planning Systems for the HP 3000 


Using a hypothetical manufacturing company, Mr. John Gewecke presented an 
overview of a Financial Planning System which may be purchased or leased to 
the HP 3000, * “FORESIGHT is a computerized financial analysis, planning and 
modeling language developed by United Computing Systems, Inc,, Business 
Information Products, a subsidiary of United Telecommunications, Inc, In use 
for over a decade, it was the first user-oriented interactive financial 
planning language to be placed on a computer system and has been continually 
upgraded and modified in response to changing business trends and computer 
technology. 


FORESIGHT is based on the concept of a matrix, The matrix is made by the 
intersections of a series of lines and columns (both variable) which each 
house a data element. For example, a monthly sales forecast by marketing 
might be developed into the matrix with the sales forecast for each product 
for each of twelve months as the data elements, .A number of descriptive 
fields are added to this matrix such as the date, sales division, report 
title, and descriptions unique to the report, With a price per unit for 
each product determined by marketing, a Planned Product Sales report may be 
produced, This report will show the forecast number of units sold and gross 
sales by product for the division on a monthly and annual basis, 


Based on these results the manufacturing department may determine the 
necessary lead time for production and indirect cost and overhead may be 
forecast, From this input, a Cost of Goods Manufactured report is produced, 
At the Finance Director's level, most of the detailed information is not 
required so a Profit and Loss report is produced using only those totals he 
wishes to see and including additional corporate level items of interest 
(Depreciation, General and Administrative expenses, Bonuses ). 


A similar set of reports is produced for each division, From divisional 
outputs, a series of higher level reports can be easily attained, By the 
use of the FORESIGHT “consolidate and merge" command a Consolidated Profit 
and Loss statement is produced, At higher corporate levels a variety of 
additional reports may be required using the exiting data base of infor- 
mation, A Comparative Profit and Loss statement is produced using the 
"consolidate and select" command, 


At each higher level, additional logic can be added to specified results 
extracted from the original data base utilizing FORESIGHT's format file 
capability. For the final presentation to the President, the advanced 
report writer capability may be called on to produce a more finished report 
in a format designed by the user, 


Ann Minger 
Metropolitan State College Student 
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FINANCIAL MANAGEMENT SYSTEM DESIGN 


The scope of the design of a financial management sys- 
tem should not stop with general accounting applications, 
according to C.E. McVaney of J.D. Edwards & Company, but 
should encompass all facets of financial manacement reporting 
in such a way that each level of management is provided with 
the most timely and appropriate reports for decision-making. 


The system designer should begin with the general ledger 
accounts, then using the top-down approach, determine what 
data is necessary to “beef-up" the ceneral ledger to create 
an accounting report data base. Main components of this 
data base should include: the general ledger, the cost ledger, 
the chart of accounts, the general journal, sample trial bal- 
ances, and audit lead schedules. 


Three basic report types should be generated by the sys- 
tem: 1) general accounting reports for the accountinc and 
budgeting levels of management, 2) budget plans and 3) vari- 
ous management summaries which should be set up so that the 
lower the level of management, the higher the amount of detail 
in the report. 


Reports cenerated by a complete financial management sys- 
tem ideally would include most of the following: Key Variable 
Reports, Return on Investment analyses, Responsibility Reports, 
Planned vs Actual Reports, -Prtor Year Comparisons, Prior Month 
Comparisons, Financial Ratios, Per Cent of Completion ?eports, 
Analysis of Seasonal Fluctuations and Cost and Profit Center 
Reports in addition to\the common general accounting reports. 
The system desicner should also consider including applicable 
statistical analyses and exception reports which would aid 
management. 


_ In summary, a financial management system designer should 
Strive to meet management's needs for timely information 
throuch enhanced reporting which will serve both management 
and operations. 


Mary Farris 
Metropolitan State 
College Student 
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APPLICATIONS 
GRAPHICS IN BUSINESS APPLICATIONS 


The use of graphics in scientific applications has long been an 
accepted way of showing information pictorially. Mr. Cooper 
Suggests that graphics in business can also have more impact than 
common rows of numbers and statistical data. 


Graphics is a better way of reporting because it more clearly 
illustrates both good and bad points which numerical data alone 
obscures. Another reason to increase use in business applications 
is the relative ease of programming a graphics problem (1.E. a pie 
chart fortran program accepting up to ten variables with approxi- 
mately two hundred statements). 


Two CRT terminals are presently available from H-P with graphic 
capabilities. These are the models 2647A and 2648A. They feature 
A 32K bit memory (A bit for each dot on the matrix screen). These 
can stand alone or be used with a computer. The autoplot feature 


is available which allows the user to make graphs by simply entering 


parameters for the X and Y axis. Columnar data can come from three 


sources; (1) typed in; (2) computer; (3) cassette. Loading the plot 


takes less than one escape sequence. 


Graphic software is now available for the 264/7A. 


Je. Aw Vuletich 
Student 
Metropolitan State College 
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GRAPHICS IN BUSINESS APPLICATIONS 


Mr. Paul Cooper, an HP Systems Engineer from Tulsa, Oklahoma, 
started with a slide presentation on the graphic applications 
available with the 2648 terminal. He pointed out that graphics 
have been used for some years in scientific and engineering work 
but are just beginning to be used in the business world. With 
the growth of distributed data processing putting more terminals 
at the disposal of more managers some of the mystery is being stripped 
from data processing and managers are finding there are better 
tools at their disposal than ever before. Speaking of five 
principle levels of managers, Mr. Cooper showed how data normally 
presented in tabular form to each could be quickly translated 
into a line graph showing actual production levels, or efficiency 
levels or net worth figures on a comparative basis. Through 
use of interactive terminals throughout a manufacturing facility 
management has the capability of accessing timely data shown on 
a time continum from any terminal as soon as the production data 
has been generated by the manufacturing unit. There is no longer 
any need to wait for the analysis of a weekly production report. 
They have the picture NOW. In this manner trends can be diagnosed 
quickly, forecasts projected and corrective action taken if 
necessary before the major problem has time to develop. 


The Autoplot Menu leads the user through the steps one 
by one to build the graphic display he needs. It is a function 
imbedded in the firmware of the terminal, includes eight diff- 
erent text sizes, and will create the appropriate grid with 
increments designed as specified by the user when he supplies 
the maximum and minimum values for each axes. When supplied 
with the data required the line graph is produced on the 
terminal screen but hard copy can be obtained by using the 
2648 to drive the 4 pen plotter, Plot 21 or a matrix printer. 


Mr. Cooper has also included in his paper which will be 
published with the proceedings the source listing of the 200 
statement FORTRAN program which will generate a pie chart. 


At this point Mr. Cooper feels that the technology of 
computer graphic representation has outrun the imagination 
of business to utilize what could be produced, and they are 
looking for input from users in business to show them direction 
for further development in this field. 


C. Mallette 
Student 
Metropolitan State College 
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DATA MANAGEMENT 
Transaction Processing 


In the development of new methods of transaction processing, 
Decision Strategy Corporation of New York has developed a new 
processor intended for use with HP hardware. 


The new processor is called a Terminal Application Processing 
System (TAPS). Some business objectives of TAPS are listed below: 
1) To replace manual processing of orders 
2) To cut the invoice to shipment response time 
3) To provide order management tools 
4) To standardize proceedures in processing 
5) To create a vehicle for decentralization 


In a typical manufacturing operation, TAPS allows many opera- 
tional areas within the firm to initiate inquiry and update func- 
tions with a main computer, typically the HP-3000. 


Management benefits include information by-products and informa- 
tion summaries stemming from automated transactional analysis. 


Operationally, TAPS is sub-divided into three main functional 
areas: 
1) TAPS/CM - the communications monitor 
2) TAPS/AM - the applications manager 
3) TAPS/DM - the data manager 


As basically a table driven system, TAPS offers many unique 
benefis over manual and other automated processing systems. Some 
basic features include increased data security, accelerated 
transaction processing, and an inquiry/update function. Other 
important and unique features warrant more complete explanation. 


TAPS assigns a numeric value to variables which enables it to 
become language independant. This will allow TAPS to become 
compatible with virtually any hardware and software packages. In 
addition, TAPS is also format and device independant allowing the 
user to define new areas of data and not have to rewrite the program. 
Independance from language and device restrictions will allow TAPS 
to be adaptable to different applications; a must for future 
developments in hardware and software. In application development, 
TAPS will reduce changeover from 95% required under normal cir- 
cumstances to 5%; generally only input/output changes. 


The Terminal Application Processing System can be a valuable 
tool if your business organization utilizes large amounts of 
transactional data. TAPS, aS an aggregate tool, replaces 30% of 
a typical transaction system and tabulizes 25% of the development 
work. In addition, statistics indicate that 30% of the devel- 
opment effort can be saved. Savings on maintenance exceed 50%, 
because the nature of most maintenance is simply a table change 
to TAPS. An orientation meeting with a representative of 
Decision Strategy Corporation may well be time well spent for an 
organization with large transactional requirements to process. 


Richard Rehm 
Student 
Metropolitan State College 
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IMAGE DATA BASE DESIGN 
AND PERFORMANCE MEASUREMENT 


Mr. Orland J. Larsen, IMAGE 3000 Product Manager, 
addressed this session on IMAGE, IMAGE 3000 and IDEA were the 
topics discussed, 


The steps to design a data base included determination 
of the information needed to make decisions, the actual design, 
the data base dictionary and activity against the data base, 
This last step is where IDEA comes in. IDEA stands for IMAGE 
Data Base Evaluation Analyzer. The service that this software 
provides include: 


le A calculation of the estimated load time 
2. Response time 

3e Throughput 

he Provides initial design feedback 

5 Provides future change impact 


IDEA is now available for Series I and II. Series III 
is expected to be announced scon. The main concern is that 
IDEA does not always work with MPR III. HP is currently worke- 
ing on this problem, HP also expressed the desire for input 
rig — as to its usefulliness to determine the future 
of IDEA, 


IMAGE 3000 has been named to the Data Pro Software Honor 
Roll. it has received the highest user ratings in all 
categories of any other data base. This included a 3.8 
overall satisfaction rating. 


Kelly J. Patterson 
Metropolitan State College 
Student 
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Data Management 


Mr. D.C. Dummer of 9.C. Dummer and Associates, Calgary, AB spoke on 
"Data Management - Information Management - An Investment for the Future." 
He discussed the problems and advantages of using the data base approach. 


The definition of data base, often a misued term according to Dummer, 
is an accumulation of raw data which you can use for decision making. In 
decision making you do not make the right decision, you make tne best 
decision. 


In introducing a data base management system (DBMS) to an organization, 
there may be resistance to change in methods and procedures, loss of data 
cwnership and data control, change in power structure, change in the status 
of EDP users and in staff requirements. However, there are corporate 
opportunities which off set the resistance to change. ‘These include 
improved data utilization, methods and procedures, reduction in cost and 
improved control. 


Information must be brought together from different departments to 
form a centralized information system. Benefits derived from centralized 
record files include improved training facilities, controlled introduction 
of new technology, protective mechanisms and procedures for data resources 
and easier transition from system to system. 


Some practical requirements of data sharing that must be considered 


1) Data Integrity 
“accuracy of data 
-currency of data 
“usability of data 
2) Data Security 
What to Protect? 
-data items and data files 
-computer memory and data storage devices 
-data listings and information reports 
-data transmissions 
-security system(s) and procedures 
Protecting from what? 
-human and system errors 
-environmental accidents and catastrophes 
-mischievousness and fraudulence 
-industrial and political espionage 
3) Data Dictionary and Directory 
They are used to define data and structures. The data dictionary 
and directory should reflect the relationship between data administra- 
tion, maintenance group, systems group and the user. 
4) Backup and Recovery Procedures 
Backup is a utility that restores the data base or some portion of it 
to a particular state after a situation occurs that causes the data base 
to lose its integrity. A recovery procedure uses the backup copy of 
the data base at the checkpoint plus the system journals to generate 
anew copy of the data base to the point just prior to the failure. 


Data Management (con't) 


5) Audit Trail 
The design of the system so that any transaction, total, or resulting 
output may be traced back to the original source, 


Before selecting a data base management system there are several inital 
considerations. One important point to consider - is a DBMS really 
necessary? Other considerations are: Avoid home built DBMS, concentrate 
on the immediate payoffs, and access risks involved in committing to a 
partial DBMS. Also you should compare the record of the vendor and the 
data base with other users, 


The ability to access a data base by an individual within an organiza- 
tion offers great potential for the efficient management of a business 
organization. Data base management systems will play an increasingly 
greater role in system design because of the advantages they offer in terms 
of cost, control, and the ability to store and access data. 


Beverly Kelman 
Metropolitan State College 
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TIPS AND TECHNIQUES FOR THE NEW USER 
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THIS SEMINAR WAS DESIGNED FOR USERS WHO HAVE PURCHASED THE 
HP IMAGE DATA BASE. 

ONE PARTICULAR TIP WAS TO AVOID THE USE OF SORTED CHAINS 
WHERE THERE ARE A NUMBERS OF "PUTS" AND "DELETES". SINCE 
QUERY ONLY REPORTS 136 RECORD SIZE POSITIONS SOME USERS RELATED 
THE NEED FOR MORE. ONE POSSIBLE SOLUTIONS WAS TO USE THE EDITOR 
AND ADD ONE FILE TO THE OTHER. 

QUESTIONS CONCERNING MANUAL AND AUTOMATIC MASTER WERE BROUGHT 
UP. IN AN AUTOMATIC MASTER IT IS IMPOSSIBLE FOR VALUES TO BE V 
VERIFIED SINCE IT IS AUTOMATICALLY ASSUMED TO BE CHECKED. A 
MANUAL MASTER IS NOT SO VOLATILE. IT CREATES A TABLE OF LEGITIMATE 
VALUES. IF A VALUE IS NOT FOUND IN THE TABLE OF LEGITIMATE VALUES 
IT IS DISCARDED. 

STAND-ALONE DETAILS GIVE THE IMPRESSION OF A MPE FILE SO 
QUERY CAN BE USED AND SOME SECURITY CAN BE ASSIGNED. STAND-ALONE 
DETAILS ARE USED FOR TRANSACTION LOGGING. 

IF A USER HAS A REQUIREMENT FOR MORE THAN 255 FIELDS (THE FIELD 
LIMITATION FOR THE DATA BASE) EVERY EFFORT SHOULD BE MADE TO DISCUSS 
WITH THE USER THE REASON WHY THE THINK THEY NEED MORE FIELDS AND 
WHAT EXACTLY WHY THEY WANT TO USE QUERY. 

FOR LISTING PURPOSES IT WAS SUGGESTED TO USE "**" INSTEAD OF "@". 
THE FORMER IS SEVEN TO NINE TIME FASTER FOR EACH DATA SET. THE 
LATTER WILL LIST ALL ITEMS. ANOTHER ADVANTAGE OF "**" IS THAT IT 
USES THE PREVIOUS LIST THAT HAS BEEN PROCESSED AND KEPT RATHER THAN 
CHECKING THE ALGORITHM. 

THE QUERY COMMAND "NUMBERS" WAS SUGGESTED TO FIND AND SELECTIVELYY 
GO DOWN AND COMPARE THE QSLIST TO A DISK FILE. "NUMBERS" WILL SET 
UP A QSLIST FILE THAT CAN BE BROKEN DOWN. 


NANCY L. YELLOTT 
METROPOLITAN STATE COLLEGE 
DENVER, COLORADO 
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VIEW/3000: A NEW TOOL 


THE VIEW/3000 SYSTEM, AS PRESENTED BY JUTTA KERNKE OF HEWLETT- 
PACKARD'S GENERAL SYSTEMS DIVISION, IS A VERSATILE NEW SOFTWARE PACKAGE 
FOR DATA ENTRY. VIEW/3000 CONSISTS OF FOUR MAJOR FACILITIES: FORMS 
DESIGN, SOURCE DATA ENTRY, DATA REFORMATTING, AND PROGRAM INTERFACE. THE 
FACILITIES ALLOW THE USER TO CREATE INTERACTIVE DATA ENTRY SCREENS IN A 
"FILL-IN-THE-BLANKS" MANNER WITHOUT COMPLICATED PROGRAMMING EFFORT. THE 
FORMS DESIGN FACILITY WILL ALLOW THE USER TO INCLUDE DATA EDITING SUCH 
AS LENGTH CHECKS, RANGE CHECKS, TABLE CHECKS, EQUALITY CHECKS, PATTERN 
MATCH, AND CHECK DIGIT VERIFICATION. VIEW/3000 WILL ALSO JUSTIFY, FILL, 
UPSHIFT, AND STRIP DATA INTO A PRE-DEFINED FORMATTED FORM. VIEW/3000 
WILL ALSO ALLOW DATA TO BE MOVED BETWEEN FIELDS ON A SINGLE FORM OR 
BETWEEN SEVERAL FORMS. ARITHMETIC AND CONDITIONAL PROCESSING ON THIS 
SYSTEM CAN BE USED TO TRIGGER CUSTOM ERROR MESSAGES AND LINK SEVERAL 
FORMS TOGETHER. MS. KERNKE POINTED OUT THAT VERY SOPHISTICATED FORMS 
COULD BE CREATED VERY EASILY. MODIFICATIONS TO EXISTING FORMS ARE ALSO 
VERY SIMPLE PROCESSES. 


VIEW/3000 CAN BE USED INTERACTIVELY WITH AN APPLICATION PROGRAM 
OR IT CAN ACT AS A STAND-ALONE DATA ENTRY FACILITY. USERS CAN USE THE 
SYSTEM TQ CREATE EDITED AND FORMATTED FILES OF DATA. THE DATA ENTRY 
OPERATOR CAN "BROWSE" EXISTING DATA FILES AND VERIFY THEIR CONTENTS. 
THESE DATA FILES CAN ALSO BE REFORMATTED TO MEET THE APPLICATION 
PROGRAM'S REQUIREMENTS. FOR EXAMPLE, DATA FROM SEVERAL FORMS CAN BE 
COMBINED INTO ONE BATCH FILE. THE REFORMATTING IS A BATCH PROCESS WHICH 
CAN BE DONE AFTER ALL THE DATA HAS BEEN ENTERED. 


MS. KERNKE NOTED THAT VIEW/3000 MUST BE USED ON AN HP/3000 SERIES 
COMPUTER WITH AT LEAST 256KB OF MEMORY AND OPERATING UNDER THE MPE-III 
OPERATING SYSTEM. ALSO, THE KSAM (KEYED SEQUENTIAL ACCESS METHOD) 
SOFTWARE MUST BE AVAILABLE FOR VIEW/3000'S USE. THIS SYSTEM IS DESIGNED 
FOR USE WITH THE HP264X SERIES OF CRT TERMINALS AND AT LEAST 4K OF 
TERMINAL MEMORY IS ADVISED. GIVEN ITS VERSATILITY AND SOPHISTICATION, 
VIEW/3000 SHOULD PROVIDE ITS USERS WITH A GREAT DATA ENTRY TOOL. 


WILLIAM L. BLANKENSHIP 
STUDENT 

METROPOLITAN STATE COLLEGE 
DENVER, COLORADO 


C-03 
Process Optimization - On-Line Programs 


Optimizing on-line programs is an important issue for all users of 
any computer system. This view is clearly one Robert M. Green of 
Robelle Consulting LTD. took in the formation of his firm. The 
goal of optimization is to get the most productivity from your 
system's resources. This is a rather broad statement and goal 

to achieve, it also requires a broad perspective to deal with it. 
To aid in this goal, Mr. Green has outlined five basic ideas or 
principles for on-line programs. They are: 


1) Make each disc access count 

2) Maximize the value of each terminal input 
3) Minimize the run-time program size 

4) Avoid constant demands for execution 


5) Optimize for the common event 


These are general rules which should be kept in mind in designing 

a program or the structure in which the program will work. The key 
to optimization is make the system resources open for all users of 
the system and not to overload the system by doing so. Consquently, 
the user should establish a priority system to do jobs and in that 
priority system optimize for the common event in a particular job. 
This sorting process should be rational in that optimizing a high 
priority job that doesn't occur frequently would in essence be 

a waste of resources. 

Perhaps the effectiveness or usefulness of any of these basic 
principles must be weighed on a cost vs. benifit analysis. An 
arguement against optimization or more precisely one against dele- 
gating much time to it, is that optimization is a fuction of memory. 
What I mean here is that a system will be suitable for the user's 
need if there is enough memory. This belief is furthered by the fact 
that memory will get cheaper as time passes. I believe this view 
will cause a tangled mess as poor documentation does. Optimization 
intergrates processes with the computer as well as within the computer 
enhancing throughput and reliability. In a burgeoning data and 

data processing environment optimtzatdon is still an important issue. 


John L. Fong 
Metro State College 


TNSTALLATION MANAGEMENT 
SYSTEM SECURITY 
D-08 


BILL GATES, WHO GAVE THE SPEECH, IS ASSOCIATED WITH LONG DRUG 
STORES, INCORPORATED LOCATED ON THE WEST COAST. 

LONGS IS UNIQUE IN THAT ITS OPERATIONS ARE DECENTRALIZED AND IT 
HAS NO CENTRAL WAREHOUSE OR SYSTEM. LONGS LACKED A GOOD SECURITY 
SYSTEM UNTIL THEY HAD A DATA PROCESSING AUDIT A FEW YEASRS AGO. THE 
AUDITORS SUGGESTED THAT LONGS MAKE CHANGES TO THEIR EDP OPERATIONS. 

ALL PROGRAMS ARE RUN FROM APPLICATIONS GROUPS. THEY CAN ONLY 
ACCESS DATA WITHIN THE GROUP EXCEPT FOR CERTAIN DATA BASES. 

FOR THE BACK-UP PROCEDURE LONGS ELECTED TO USE "STORE" RATHER 
THAN “SYSDUMP". THE REASONS FOR THIS IS THAT "STORE" MAY BE SELECTIVE 
THAT IS, ONLY FILES THAT ARE NECESSARY IN CASE OF DISASTEER ARE STORED. 
"SYSDUMP" HAS THE DISADVANTAGE OF NOT DUMPING FILES THAT ARE CURRENTLY 
IN USE. "STORE" MAY BE RUN DURING OTHER PROCESSING. 

MOST BACKUP IS DONE BY THE APPLICATION GROUP. ONLY FILES 
NECESSARY FOR RECOVERY, IN CASE OF CRASH, ARE STORED. THE FREQUENCY 
OF SYSTEM DUMPS DEPENDS ON THE APPLICATION GROUP. A COMPLETE SYSTEM 
BACK-UP IS DONE EACH EVENING AT 6 P.M. 

A "CONSOLE OPERATIONS PROGRAM" CAN ACCESS THE PRODUCTION JCL FI 
FILE. IT READS JOB STREAMS INTO A TEMPORARY FILE AND ALLOWS THE 
CONSOLE OPERATOR TO ENTER PROGRAM "PARAMETER CARDS". IT THEN STREAMS 
FROM THE TEMPORARY FILE. THE PROGRAM DOES AN INTRINSIC CALL RIGHT 
INTO THE DIRECTORY TO FIND THE APPROPRIATE PASSWORD AND INSERTS IT 
IN THE JOB RECORD. 

FOR SYSTEM MAINTENANCE THE "GOLD BOOK" IS KEPT UP TO DATE. 

THIS LOG CONTAINS THE SYSTEM FAILURE LOG, MAINTENANCE LOG, COPY OF 
SERVICE CONTRACTS AND A COPY OF THE CURRENT CONFIGURATION. 

A "SYSDATA" JOB IS RUN EACH MONDAY MORNING. THIS JOB HAS 
NUMEROUS LISTINGS OF FILES, FILE SPACE, AND A DATA. BASE UTILITY 
LISTING. THESE ARE ALL REVIEWED AT DEPARTMENT MEETINGS. 

THE CURRENT PHYSICAL SECURITY AT LONGS IS SIMPLY RESTRICTED 
ACCESS TO THE COMPUTER ROOM. STANDARD APPLICATIONS CONTROLS IN- 
CLUDES DIVISION OF RESPONSIBILITY, EXTERNAL INPUT AND OUTPUT 
BALANCING BY USERS, AND USER APPROVAL OF PROGRAM CHANGES. ACCESS 
TO THE DATA IS RESTRICTED BY THE USE OF PASSWORDS, USER CAPABILITIES 
WITH SOME USERS ONLY ABLE TO "READ", AND EDP DEPARTMENT RESTRICTIONS 
WITH PROGRAMMERS ACCESS LIMITED. 

DATA ACCESS IS AUDITABLE. THE AUDITOR REVIEWS EVERYTHING 
THAT GOES ON. WHEN A JOB IS TO BE RUN THINGS MUST BE TIED TOGETHER 
WITH A JOB REQUEST SHEET, $STLIST, CONSOLE AND SYSTEM LOG. 

DISASTER CONTINGENCY PLANS HAVE BEEN IMPLEMENTED. A HALON FIRE 
PREVENTION HAS BEEN INSTALLED. THERE IS ALSO OFF-SITE BACK-UP OF 
FILES. AFTER A DISASTER HAS OCCURED AN EXPENSIVE AND TIME CONSUMING 
SOLUTION WAS INSTIGATED: BACK-UP SITES FOR THE COMPUTER AND A BACK-UP 
LOCATION FOR USERS. 

MR. GATES STRESSED THAT SECURITY IMPLEMENTATION IS A GRADUAL 
PROCESS. THE COMPUTER ROOM WAS AT FIRST WIDE OPEN AND IT WAS THEN 
GENERALLY CLOSED OFF. PASSWORDS ARE CHANGED WEEKLY AND THE SYSTEM 
MANAGER PASSWORD IS KNOWN ONLY BY THREE PEOPLE. THIS PASSWORD IS 
CHANGED AFTER IT IS GIVEN OUT. 

ANOTHER POINT BROUGHT OUT WAS TO INVOLVE EDP AND USER PERSONNEL 


IN THE SECURITY PROCESS. EXPLAIN THE TRADE-OFFS, CHALLENGE PERSONNEL 
TO DEVELOP GOOD SECURITY REQUIREMENTS AND EFFICIENT PROGRAMMING 
TECHNIQUES. ALSO VARYING DEGREES OF COMPLIANCE WITH SECURITY 
MEASURES ARE FELT BE PERSONNEL. THESE SHOULD DECREASE OVER TIME 

AND FAMILIARITY WITH THE NEW PROCEDURES. 


NANCY L. YELLOTT 
METROPOLITAN STATE COLLEGE 
DENVER, COLORADO 


E04 


WHAT'S AHEAD IN COBOL 


Mr. Greg Gloss of HP's General Systems Divsion conducted this 
session on the changing world of COBOL using three main topics to guide 
the presentation and discussion. First he discussed some of the new 
features proposed for the '74 COBOL followed by suggestions for the 
conversion from '68 COBOL and finally a few comments on '80 COROL. 


Users were urged to start programming now with the conversion 
in mind so that the transition will cause a minimum of disruption 
to the operation. The major changes in programming '74 COBOL will 
involve changes in some COBOL statements, changes in the reserved 
word list and changes in the treatment of comments. These changes 
are covered in detail in the Conversion Guide which was available in 
a preliminary form. 


New in the standard '74 COBOL include indexed I/O, relative 
I/O, which checks for the presence of data on the file record, enhanced 
SORT and MERGE, STRING and UNSTRING verbs to concatinate data with 
delimiters and unconcatinate fields, and Multiple Copylib Files. 
MERGE becomes a part of the language and the SORT verb will permit 
multiple input files. The EXAMINE verb is replaced by INSPECT and 
REMARKS and NOTE paragraphs are eliminated to be replaced by the * in 
column 7. 


There is now a conversion guide program available which will flag 
any COBOL statement in a program of '68 COBOL if that statement requires 
reprogramming before the program can be used after the conversion. It 
does not make the correction it just shows what will have to be changed 
giving the user a chance to plan the stages of hs conversion. 


Improvements in the COBOL language standards are attempting to 
eliminate some of the error prone statements, making programs faster 
to debug and more reliable to run. The changes are being aimed not at 
improving compilation time but in shortening runtime once the program 
is compiled. This makes for greater efficiency in the production 
environment and it is hoped will allow production to run 30 to 40 
percent faster. 


As a member of the ANSI COBOL committee, HP is seeking input from 
users about what they would like to see in the next version of COBOL, 
currently being called COBOL 80. So far suggestions include: 

CODASYL DATA BASE FACILITY, reference modification, 48 levels of 
subscripting and a USAGE BIT. Plans include gradual phasing out of 

77 and 66 level data items, Label Records clauses, Value of clauses, 
Add/Subtract Corresponding, Alter statements, the picture character 'A', 
most of the Identification Division paragraph and the INSPECT TALLYING 

- - »« REPLACING verb which is coming in as part of '74 COBOL. Some file 
related clauses would be moved from the environment to the data division. 


During the question period questions included the ability to use 
SET for a condition value, a method of tying nexted IF's to their own 
ELSE's, debugging features and the creation of permanent files. 


C. Mallette 
Student 
Metropolitan State College 
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SPL/3000: SYSTEM PROGRAMMING LANGUAGE 
PART I OF II 


R. SCROGGS, OF NOEISIS IN SAN FRANCISCO, PRESENTED AN INTRODUCTION 
TO SPL/3000. SPL/3000 IS THE IMPLEMENTATION LANGUAGE ON THE HEWLETT- 
PACKARD SERIES 3000 COMPUTERS. IT IS A HIGH LEVEL LANGUAGE OF MUCH 
VERSATILITY. THE LANGUAGE ALLOWS THE USER TO CREATE PROCEDURES, 
TO UTILIZE SUBROUTINES, TO PERFORM LOGIC UNDER CONDITIONS, TO CODE 
NESTED IF-THEN-ELSE SEQUENCES, AND MANY OTHER SOPHISTICATED LOGIC 
SEQUENCES. WHILE SPL/3000 INCORPORATES MANY HIGH LEVEL LANGUAGE 
FACILITIES, IT ALSO ALLOWS THE USER TO DIRECTLY MANIPULATE THE 
HARDWARE REGISTERS, TEST HARDWARE CONDITIONS, PERFORM BIT MANIPULATION, 
AND GENERATE MACHINE INSTRUCTIONS. 


MR. SCROGGS DEVOTED THE FIRST OF HIS TWO PART PRESENTATION TO 
THE GENERAL SYNTAX OF SPL/3000 AND THE HP/3000 ENVIRONMENT. SPECIFIC 
TOPICS COVERED INCLUDED THE FOLLOWING: 


1) DISTINCTION BETWEEN GLOBAL, LOCAL, LITERAL, AND PARAMETRIC. DATA 
2) DEFINITION OF THE STACK OR DATA SEGMENT 
3) THE VARIOUS FORMS OF SCALAR VARIABLE STORAGE--I.E. BYTE, INTEGER, 
LOGICAL, DOUBLE, REAL, AND LONG 
4) THE USE OF ARRAYS 
5) THE GENERAL FORMAT OF AN SPL PROGRAM 
6) ARITHMETIC AND LOGICAL OPERATORS 
7) THE EQUATE AND DEFINE STATEMENTS 
8) ASSIGNMENT STATEMENTS 
9) IF-THEN-ELSE STATEMENTS 
10) THE VARIOUS FORMS OF THE DO STATEMENT 
MR. SCROGGS SAID VARIOUS UNFOUNDED FEARS OF SPL/3000 HAVE CAUSED 
IT TO BE IGNORED BY MANY USERS. HE SUGGESTED THAT GIVEN THE INTRODUCTION 
AND THE REFERENCE MANUAL, MOST APPLICATION PROGRAMMERS SHOULD BE ABLE TO 
CODE IN SPL. MR. SCROGGS SUGGESTED THAT THE BEGINNER START BY CONVERTING 
SOME SIMPLE BASIC OR FORTRAN PROGRAMS TO SPL/3000. 


WILLIAM L. BLANKENSHIP 
STUDENT 

METROPOLITAN STATE COLLEGE 
DENVER, COLORADO 


ADVANCED BASIC 


E-09 


Mr. Warren Kuehner, HP Systems Engineering Supervisor, gave his presentation 
on various techniques of interfacing SPL with basic to overcome Slight misrep- 
resentations and design flaws in the HP 3000. However extreme flexibility in 


calling SPL routines within a HP 3000 made correction easier. 


Some unique characteristics of Basic called SPL routines were also presented. 
The stack marker retains information relating to the state of the machine 

when the subroutine is called. On top of the Stack, information is also kept 
pertaining to the parameters passed to the subroutine in the order they are 
passed. The number of parameters passed is totaled and codes are developed to 
determine the type of parameter passed, both features of use in diagnostics 
and both unique to Basic. It was suggested that these features be used as a 


"Cookbook" in developing subroutines. 


Other important characteristics of Basic were: 
5 | Basic calls an intermediate routine which in turn calls the SPL routine. 


2.) Basic calls by reference, not by value. 


To actually run the routines it is necessary to use a segmenter built SL file. 
If a error is detected it was suggested that the SL file be purged by use of 


the procedure call. 


Specific routines discussed were: 

1.) To overcome a flaw in DEL which limited its formated display screen for 
data entry to 255 characters. The routine would provide for longer strings. 

2.) To increase double-precision accuracy on the HP 3000 seryes 1 to 48 digits. 


3.) To obtain the MPE file number by just giving the Basic number. 


Comments : 
It was pointed out that even though Basic is a beginners language that it is 


second only to SPL in data base application code efficiency. 


Craig Morris 
Metropolitan State College 
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SPECIAL PURPOSE LANGUAGES 


Mr. M.J. Badlander of B & B Computer Company addressed 
this session on the desian and implementation of special 
purpose languages. His presentation covered the following: 


1. How to determine when a special purpose language is 
needed. If (a) the problem area can be well-defined, and 
(b) existing lanquaces are unsatisfactory, ane (c) there will 
be frequent usage of the special language, design and imple- 
mentation of a special purpose language should be considered. 


2. Considerations in designing a special purpose lan- 
guage. These include power, flexibility and naturalness of 
the language, as well as an awareness that designing a spe- 
cial purpose language is an art, not merely a technical job. 


3. Alternate methods of implementation. A special pur- 
pose language can be implemented as (a) a preprocessor: this 
method is the least difficult as well as the least costly, 
but offers limited applications and power; (b) an interpreter: 
a medium difficulty factor is involved, the cost is moderate . 
to high, and applications are limited; or (c) a compiler: 
the most complex and usually the most costly method, but pro- 
vides the most flexibility and power. 


4. Advantages of a special purpose language. The in- 
creased power of the language should result in a need for 
fewer and less complex programs. Reduced complexity would 
lead to greater reliability. Both the increased power and 
reduced complexity should simplify program maintenance. 
All three factors should result in lowered software costs. 


Mr. Badlander then presented a case involving the de- 
sign of a special purpose language - DEC/3000 - to solve 
the, following needs for a user: 1) terminal and form man-~ 
agement, 2) off-line batch development, 3) hide terminal 
details from programmers, 4) provide adequate documentation, 
5) support non-HP terminals and 6) dovetail with existing 
software. DEC/3000 was implemented through a compiler, sim- 
plifying the language, compiles into USL files, and uses a 
host language concept. It provides terminal management, 
data editting, checking and conversion, and handles input/ 
output as part of solving the user's problem. 


Mary Farris 
Metropolitan State 
Collece Student 
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APPLICATIONS DEVELOPMENT 
PAST PRESENT AND FUTURE 


Due to the increasing technological improvements occurring in 


the computer industry the use of compilers in the future will 
Change making applications programming the direction of develop- 
ment according to Mr. Couch. 


There are basically two types of compilers; algorythmic and 
Specification. Algorythmic languages provide step by step pro- 
cedures to break down a job into several individual and specific 
procedures (I.E. FORTRAN and COBOL). Specification languages are 
not interested in a major breakdown of a problem. They deal with 
a more general subject area leaving the user free of minute details 
such as specific input and output definitions (I.E. RPG). 


Historically, this is what has occurred. From 1955 - 65 a rapid 
development of algorythmic languages came about. In 1965 and up 
to 1970 high level algorythmic languages found wide acceptance. 
This was due largely to a strong push from the government and 
everyone else getting on the "band wagon". Also applications 
programming was being pushed in FORTRAN and COBOL. From 1970 and 
up until today, high level algorythmic languages are still prevelent. 
Also most applications are being written in high level languages. 


Mr. Couch sees that for the future algorythmic languages will 
still be used but specification languages will also be in wide use. 
The reason for this being the increasing disparity between hardware 
and software prices. The small user can now afford a computer but 
can't afford the software. In this way, a non-programmer can carry 
out most needs without technical expertise. 


Applications programs could provide users with packages for 
inputting, outputting and accessing data. The major characteristics 
of this system are: 


* INTEGRATION OF EDP FUNCTIONS 
* PROVIDE ADDITIONAL FUNCTIONS FOR THE NON-PROGRAMMER 
* USE INTERACTIVE POTENTIAL OF CRT 


The environment that applications programs should be used in 
is described as follows: 


FORM/DOCUMENT ORIENTED 
SCRIPT AND INTERACTIVE DIALOG MODES 
KEYSTROKE RESPONSIVE 


LIMITED PURPOSE - TRANSACTION/BUSINESS PROGRAMMING 
INFORMATION USERS SYSTEM 


+ + + + F 


J. Ae Vuletich 
Student 
Metropolitan State College 
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DATA COMMUNICATIONS 


Eric Pennala presented this seminar on data communications developing, 
from a management viewpoint, a planning and problem solving guide, 
I PLANNING 

A, The first step in selecting a communications system is to define the 

volume. 

B, Contact Hewlett-Packard salesman and S.E. once you have a basic layout. 
1. When making a selection, layout the total needs and let the sales- 
man propose a solution and let him back his proposal, 

C. Determine if you are capable of handling the system, if not, secure 

the services of someone who does know the systen. 

1. If you do not have someone who can debug the systemhave someone 
trained. 

D. Determine the terminal you will need and the specifications of it. 

E. Select a vendor, one that is reputable, can offer full service and 

as fast as possible, Stay with one vendor for the entire system if pos- 

sible, 

F, Set up a meeting for everyone involved. 

1. The primary comcern here is to get everyone to sgree. 
2e Determine the HP CPU configuration. 
3. Determine and write down the proper strapping functions. 
4, Determine the cable arangements and electrical needs, 
Ae Site preparation is important and a good area to look for 
ways to cut costs. Put pressure on the building inspectors 
to eliminate waste. 
S. Have a clear cost understanding covering all aspects of your 
communication systen,. 
6. Draw up a formal installation plan including dates and times. 
7. Put the results of the meetings on paper and send copies to 
the appropriate people; a precoution that might prove valuable 
when someone tries to do a little backsliding. 


II PROBLEMS 
A. HP system configured incorrectly. 
B, Communication system is configured incorrectly. 
C, Expect everything to be wrong, expect it! 
1. Suggestions to overcome these problens. 
A, When they install boxes and lines, label them! Include 
vendor and repair phone numbers on label, 
B. Develope communication book- label cables, ports and 
record circuit numbers. Write down recommended trouble- 
shooting procedures, 
C. Have a testout planned. 
1. Have everyoue on hand for testout, make sure they 
bring their data scopes and data analysis machines the 
first time! 
D. No cooperation or no solution. 
1. Go through normal channels first. 


Til 


2. After you have exausted every other alternative. 
A. Get MAD, Be MEAN! 
B. Work your way up through supervisors until you reach 
the person that will make something happen. Let them know 
exactly what your feelings are, chances are that person 
does not like problems and does not want to be bothered. 
You will get results. 

E. Every way to get system up fails. 

1, Get the DAYTECH Division of Bell Systems on the job, they 

have the reputation of being the elite of the communications 

field, 


SUMMARY FOR MANAGEMENT 

A. Put pressure on Hewlett-Packard, 

B, Willingness to get consultant, know and accept you will have 
problems, 

C. Planning and Knowledge are the key words in communication systems. 


Michael L, Hooks 
MSC Student 
DENVER, CO 
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DATA COMMUNICATIONS ON THE HP 3000 


The first session of a two-session series of presentations by Charles J. 
Villa Jr. from Alter*Ability of San Francisco, addressed the rudiments of data 
communications. Even so, the session was, due to time constraints, limited to 
what Mr. Villa called "a cram course in HP 3000 Datacom". So, a limited back- 
ground in the datacom field was a necessary prerequisite for a professional und- 
erstanding of the material. At one point during the discussion, Mr. Villa 
queried the group as to how many present had basic knowledge of datacom funda- 
mentals. Suprisingly, about half of the audience held up their hands. 


At the outset, it was said that the field of datacom was one that was fas- 
cinating and rapidly changing. 


An adequate datacom network can gather data on personnel very quickly and 
efficiently. Also, development of safeguards to deter invasion of privacy of 
data has advanced considerably in recent times. 


A basic concept of datacom is that data transmission is accomodated over 
voice networks that are modified in that the data signals (digital) are converted 
to analog signals (voice) before transmission. This process of modification is 
done by a modem, or a modulator-demodulator. 


Certain communications disciplines called protocols are used to provide a 
set of procedures for establishing and controlling transmissions in datacom. 
The HP 3000 recognizes three asynchrnous line disciplines: 


1. Hardwired, using no modem; the HP 3000 provides no control signals 
whatsoever, whereby control characters are inserted into a data stream for 
signalling the receiving station to perform a function or to identify the 
structure of the message. 


2. 103 protocol, full-duplex; a communications link is established that 
performs a prescribed sequence of events each time a mainframe calls a 

terminal or vice-versa. Communications is allowed in both directions at the 
same time. 3 


3. 202 protocol, half-duplex, reverse-channel; communications is allowed 
in one direction at a time here. But, FSK-type modulation (frequency shift 
keying), is normally used with this protocol; FSK is a form of modulation 
using two separate frequencies to represent the two binary digits (0 and 1). 


The state of the art in modems is presently the Dataphone Data Set 212A 
produced by the Bell System, Mr. Villa stated. When the terminal operator 
dials the computer, communications is established between the modem and the 
computer, when the 212A modem is utilized. 


A discussion of pin numbers, which are used in interface curcuitry in 
modems when connecting cables ensued, in which a series of questions from 
the user portion of the audience arose. The technicality of this concept 
appeared to be above that of the rudiments of datacom. 
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DATA COMMUNICATIONS ON THE HP 3000 


A hand-out entitled "Term Type Table" depicted in tabular form the individ- 
ual characteristics of 14 kinds of communications terminals applicable for use 
with the HP 3000 computer. A significant portion of the table was devoted to the 
requirement or lack thereof that the terminals have syne characters and how many 
were required for each terminal. A syne character is a character of a defined 
bit pattern that is used by the receiving terminal to adjust its clock and ach- 
lieve synchronization. Other characteristics listed were response to delete 
function and forms feed, line feed and carriage return options, and speed in 
characters per second. 


A noteworthy statement from the handout was "the definition of the remote 
terminal's function determines the desired speed of the terminal and the volume 
of data to be handled, which determines the type of datacom line and equipment 
needed, which determines not only the required hardware for the HP 3000, but 
also the configured terminal subtype. And, we must not forget the log-on term- 
inal type, which determines the control characteristics for the log-on terminal 
for the duration of the current datacom link". 


Léased lines have the aspects of a hardwired connection to the HP 3000, 
and no real documentation available. 


In datacom jargon, a signal that is "high" is one that is on. 


The second session covered the equipment and elements required in setting 
up a datacom network. Three major types of equipment contribute to a datacom 
networks: Datasets (modems ), data distributors, and data convertors. 


Probably the most dollars can be saved in network structures by choosing 
the proper dataset. Factors such as operational distance, minimum speed, type 
of line service (leased or switched), line discipline, and configuration are all 
to be considered in determining cost/effectiveness of a given dataset. 


Operational distance was expounded upon as follow: :; 
1. line drivers are not designed to work on phone lines (5 to 10 miles ); 


also, they require a de continuity from end to end. If two points are 
within the same wire center, a modified 3002 circuit is achieved. 





2 short haul modems work over a 3002 circuit (10 to 50 miles). 
3. long haul modems work over voice grade lines with DAA interface. 


Data distributors can also reduce network costs by choosing wisely. Data 
distributors are more widely known as multiplexers, which are devices that 
allow the use of one facility for two or more simultaneous data paths. FDM 
(frequency division multiplexing) works at low speeds and costs less. TDM (time 
division multiplexing) works at high speeds and costs more. 
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DATA COMMUNICATIONS ON THE HP 3000 


Statistical multiplexers are the state of the art, and more efficient 
use of communications lines is realized through their use. 


Data convertors are devices that convert asynchronous signals to synchro- 
nous Signals. 


As to types of line services, it was mentioned that switched lines experi- 
ence more noise but cost less, while leased lines have a fixed cost (higher) 
but noise is not a significant factor to contend with. 


Another new concept in networks is the Value Added Network. An example of 
this concept is Telenet, which uses packet switching. In Telenet, a call can be 
made to long distances at local call rates. In packet switching, the terminal 
delivers up to 128 characters to the network; the network takes the packet and 
sends it through the most efficient routing. Term type 13 supports packet 
switching on the Telenet network. 


The last concept covered was digital circuits, which regenerate and 


amplify signals instead of converting them to analog signals for transmission. 
The signal stays in a digital state and provides for low-bid circuits. 


Presentation by: Charles J. Villa dr. 


Summarized bv: Patrick G. Dulskv 
Metronolitan State College Student 
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Program Scripting for Custom Transaction Entry 


Mr. De. De Brown of the Nice Corporation in Ogden, Utah addressed this 
session on System Design. He discussed how his company developed SPICE/ 
3000 (System Processor Instant Consumer Exchange on a HP 3000 computer). 


The software used is COBOL for transferability. The programs are 
modular, that is they are transaction driven. This was necessary because 
when the company started development, they didn't know what the software 
would be required to do. 


The data file system is composed of a master file, stat file, procs 
file, and a utility file. 


1. Master file: each record is 256 bytes long. It was stressed 
the buffers should end on even multiples. If not, if the computer is 
being shared, the system will assume thet there are no buffers and this 
multiples the time needed by the number of users. 


2. Stat file: provides pointers for each item. It also shows the 
first transaction to take place each day. 


3. Procs file: provides all the dialogue that comes out on the CRT 
screens. This file contains all the routines and subroutines thet are 
used, 


4, Utility files: contains all the embellishments that are in the 
system: messages like "Good Morning" and messages telling the people 
that are operating the CRT's what to look out for. 


The features of SPICE/3000 are: total modulability, on-line evalu- 
ation, security, data base integrity is continuously tested, and there is 
Mag tape backup. Also, if the system goes down, the most that would be 
lost is one transaction. 


The Nice Corporation handles 20 to 25% of all calls in response to 
television commercials advertisire products such as record albums in the 
country. They presently have 28 phone/CRT operators and are planning to 
expand to 45 by the first of next year. 


Bill Brunson 
Metropolitan State College Student 
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SYSTEMS DEVELOPMENT 
System Testing & Reliability 
Software Quality Control 


Mr. C. E. McVaney of J. D. Edwards & Co. addressed this session on 
"Computer Systems Software Quality" and described in his presentation what 
might be called the three phases of data software. 


First, there was the “age of survival" and in this time period programs 
were written just to get the job done with no foresightedness as to modifica- 
tion or changing perimeters. There was no such thing as documentation and if 
there was, it was of a very poor quality. Do everything for today and let 
tomorrow take care of itself. 


Next there came the “age of high quality". In this second phase the ori- 
ginal program had proven themselves to a certain extent and now comes the time 
for modification as well as an extensive look as to the maintenance cost in 
keeping this system of starting from scratch. There is now more foresight as to 
what the future will hold for these programs and documentation is being upgraded. 
A new word is introduced-standards. With the introduction of standards every 
programmer is able to write a program that is structural and uninformal so that 
someone else may work on it and understand it after he has left that to converse 
about some data element and everybody knows what the other person is talking 
about. 


The third phase is where we are today, "The El Cheapo Software". The 
time and money invested in developing your own software may be less profitable 
due to the fact that there are so many firms today who can or have produced the 
systems that you may need. Watch out for what looks extremely cheap today may 
cause you extensive headaches and high maintenance cost tomorrow. As with any 
commodity, shop around for the best deal that will not only benefit you today 
but will require less work and money to modify it in the future. 


_ Programs today are written with seventy-five percent “grunt work" and 
twenty-five percent genius. The term “grunt work" refers to the fact that 
there is only a certain number of ways in writing particulars types of soft- 
ware for a system. i.e.-Accounts Receivable-there is only a limited number 
of ways to write a program to do an add, deletion or an updating. The twenty- 
five percent genius comes into play when adapting the program to an user's 
system and in doing, use the least amount of storage and maintain data integrity. 


By not taking advantage as to what program and services are being offered, 
management may view the problem as one concerning itself with the hardware. If 
this happens, management may acquire more hardware than is really needed and 
this is referred to as the "Iceberg Effect". The problem appears to be one of 
hardware but upon a closer look, the real problem or problems may be deep down. 
Such things to look at are: computer programs, system documentation, input con- 
trol, procedures-both operating and clerical, data bank information and lastly 
the reports for both management and eperating systems. So by only seeing the 
top of the iceberg more hardware was added on and the problem went away. You 
were just able to bury it deeper into the system and given time it will raise 
it's ugly head again only this time much higher than ever before. 


ay 


From the age of survival, through the search for quality and lastly the 
el cheapo phase, the software reliance and capability has grown at an ever 
increasing rate. It is up to management to properly use this computer tool 
to its fullest extent and not look so much at the tip of the iceberg by acquiring 
more hardware but by evaluating the whole system for its merits or demerits and 
there openly make its judgements after all the data has been gathered. 


Walter Anderson jr. 
Metropoltan State College 
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ON-LINE APPLICATION MANAGEMENT 


Mr. Dennis Dinam and Mr. Glenn Fntis,from Morgan 
Guaranty and Trust Company of New York addressed this 
session on Screen Management Off-line Generation package 
(SMOG). They discussed the needs, development and use 
of this system. 


The system was designed to work in an HP 3000 
Series II, on-line and some batch and a Multiuser environ- 
ment. Morgan Guaranty and Trust Company comprises four 
banking functions: 
1. Automated Banking System 
2. SBuro-currency Automation 
3-e Global Exposure Systen 
he New York Profitability System 
The requirements of the system were: 
1. ‘Self contained system 
2. Computer Management 
3. User and function Oriented Security 
hk. Terminal Management 
Se Full screen Support 
fhe system that was developed to meet all of the above 
conditions was SMOG. It helps the HP 265A Interactive 
Display Terminal to create and maintain files of formated 
data. It is extremely useful in instances where screens 


are changed frequently. All procedures are written in 
SPL but are accessed through COBOL, FORTRAN and SPL, 


The Terminal Application Management Program (TAMP), 
a part of this system, generally defines the application 
environment. 


Another component of the package is Key Extra Data 
Segments (KEDS). They felt KSAM was too slow for a system 
that contained many table valuations. KEDS was the answer 
and is similar to KSAM and manages tables in virtual 
Memory « 
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The design of the package has taken about two years 
at Morgan Guaranty and Trust. It is a system for the 
management and development of on-line uses and not direct- 
ly for the ond user, 


Kelly J. Patterson 
Metropolitan State College 
Student 
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The Software Development Cycle 


Mr. J.M. Grillo of HP's Genenral System Division addressed this 
session on 'The Software Development Cycle." He discussed the problems 
an the keys to success in the Development System. 


Key Problems in Development System: 


A. 
B. 


Keys to 


A. 


Implementing new management and system processes 
Skill problems 
1. Common problems 
Lack of communication between technicians and users 
2. The use of outsiders 
The risk is that the outsider might not know the Business 
3. Expertise problems 
User involvement 
Cost overruns 
Lack of detailed requirement 
1. Constant changes that the user will run into, because it 
is hard to tell when you are done. 
2. Inefficiency in programs and decumentation 


successeful system development 


User involvement 
1. Interest and support 
2. Involvement in all phases 
3. Develop acceptance test 
Personnel utilization 
1. Business analysts 
a. Define system with user 
b. Install and train 
c. Review design for conformance 
what the system should do and what the user is asking 
for. 
Technical Personnal 
1. Define and implement 
the technicians in business study should go over 
requirements with user. 
2. Review definitions for feasability 
3. Define/Develop technical environment 
How to structure Data Base Management 


Standards 


A. 


Documentation 

1. What must be documented and thought through 

2. Exposure decisions for people to make judgment on. 
Naming 

Standarized the vocabilary 

Programming techniques 

difficulty of language selection 

Formats for printed media 

Environmental standard 


Keys to success 
A. Review and Revision Procedures 
B. Phase to phase budgeting 
C. Phased development 
1. System concept phase (5% of costs of the project) 
a. Define scope and effort 
b. Review current system 
c. Identify leverage/risk areas 
d. Perform analysis 
e. Develop new system concept 
f. Task & cost estimate for General Design (cost & task 
timing) 
g. Estimate system development costs 
2. General design phase (10% of cost) 
a. Develp & detailed work program 
b. Resolve remaining issues 
c. Define inputs & outputs 
d. Define processing function 
e. Define manual procedure, personnel requirement 
& volumes 
Define technical support requirements 
Define an integrated system flowchart 
Refine cost/benefit analysis 
Order development priorities 
Develop task list and costs for detailed design 


~~ Ge pe OQ Fh 


- Refine estimate of system develpement cost 
3. Detailed Design Phase (20% of cost) 
a. Develop detailed work program task allocation 
b. Resolve remaining issues 
c. Define & desing codes 
d. Design data base 
e. Develop detailed subsystem flowcharts 
f. Specify inputs & outputs 
g. Develop program specifications 
h. Develop manual procedures 
4. Programming and unit testing (35% of cost) 
5. System testing (15% of cost) 
6. Conversion & training (15% of cost) 


Ann Sawaged 
Metropolitan State College 
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ABSTRACT 


Microprocessors; Product Design Using Microprocessors 
Presented by: J. C. Armstrong, Los Altos Research 
Presented at: Hewlett-Packard Users' Meeting, 


Denver, Co.orado, 
Octoper, 1978 


A discussion of useage of tne HP 3000 for development 
of software for microprocessor product design. 


Toe technique of using the HP 3000 in developing 
software in various developmental systems was preseated 
along witn the proolems encountered and the solutions 
developed. 

Tne use of tne HP 3000 as a large, full-scale eaitor 
overrides the cost of setting it up. Ine aavantages are 
a large editor, sophisticated editing tools, cross-reference 
facilities and multiple users. The development system box 
can ve selected after programming. Efficiencics are ootained 
as only one editor is learned--not a different one for each 
development system. Tne program documentation, reference 
manuals and user manuals can also be aone on the HP 3000 


rather than the microprocessor. 


One user writes microprocessor software on tne HP 3000, 
including program entry, cross-assemplies, deougging and 
ouputs Intel nex to the development system. A CRI input of 
assembler language to the HP 3000 goes tarouga a SPL proxyraan 
and out to a Z80 development system. Tne HP 3000 is 
"invisible" in this application. 

Another development uses tne dP 3000 editor with PLM 
language and tells the development system tnat the HP 3000 


is a teletype. 


F Jaw | all 
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A Real-Time Instrument Interface 


Mr. G. R. Symonds of Env. Health Directorate, Ottowa, has developed 

a viable real-time interface with H. P. 3000 computers. His ‘black box’ 
is an alternative to the H. P. 1000, which he considers to be overpriced. 
In his development of this interface, Mr. Symonds determinded that certain 
characteristics would be necessary. They are: immediate response, event 
driven, asynchronous, implied data lost or disaster, immediate acceptance 
or rejection, something controlling something, and subject to the vagaries 
of Murphy's Law. He concluded that this interface was similar to a data 
entry clerk and has referred to it as a impersonal one. With these 
requirements Mr. Symonds went on to try to interface with the H. P. 

3000. His first step in this approach was to determine where to branch 
into the system . Almost by default he choose the Asynchronous terminal 
multiplexer. Frequency restrictions and hampered flexibility were some 
of the problems this outdated multiplexer has. But these problems were 
nothing compared with a Selector channel or Multiplexer channel choice. 
The H. P. configuration and channel choice acts like a modem, therefore 
anything that interfaces with it must be or appear to be a terminal. The 
‘black box’ is set in line between the terminal and the H. P. 3000. As 

a backup, Mr Symonds recommends that a printer be hooked up in parallel 
with his "black box'. Because the 'black box' is not a terminal certain 
dialogue characteristics that the H. P. 3000 has with a terminal must be 
turned off. In general there must be some customizing of hardware and 
software to make this interface work. 

Opinions are varied for this hardware solution. Microprogramming 

of the terminal is possible and can achieve the same results. Costs 

are probably the biggest factor in choosing the ‘black box' solution. 

Mr, Symonds calculates around $ 800 for design and manufacture of his 
interface. This is compared with a programmer working five days at 

¢ 325, There was considerable skepticism whether this goal could be 
accomplished in that time. Mr. Symonds’ hardwire approach is cost 
effective and available in a otherwise limited area of data processing 


John L. Fong 
Metro State College 
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Data Management on the HP 3000 
MPE File System 


Four panelists, led by Mr. John Couch, recently appointed Project Director 
of the MPE File System, held a "Round Table" discussion with HP 3000 users. 
There was no formal presentation and the emphasis was placed on interaction, 
as members of the panel answered specific questions pertaining to the MPE 
File Systen, 


Users felt that KSAM reliability should be increased and that the manual 
should be changed to properly describe its use, It was specifically 
suggested that the manual should have an improved description of carriage 
control, When it was suggested that ordinary MPE utilities should work on 
IMAGE files, the Project Director for KSAM and IMAGE commented that he felt 
that IMAGE and KSAM should not be separate entities, 


In response to a question concerning the difficulties encountered with 
KSAM when a crash occurs, one of the panelists said that HP is aware of the 
problems and has identified a number of things that might be done, Anong 
those considered is the possibility of a pointer to the area at the crash 
point, 


John Couch encouraged users to send their suggestions concerning MPE to hin, 
When he asked how many of those present hesitated to turn in SMR's because 
they felt it went into the "bit bucket", two-thirds answered affirmatively, 
He then assured them that all suggestions were filed by classification and 
scrutinized carefully when appropriate changes were being considered, A 
member of the User's Group Interface Committee encouraged the users to 
contribute input to HP by filling out the annual questionnaires they receive, 


As @ wrap-up to the discussion, Mr. Couch outlined the objectives and 
strategy he is following in his new position: 


1, Reliability: Isolate as many bugs as possible (200 MPE problems 
have been identified) and assign the personnel to solve then, 


2. Performance: Double the performance of the operating system, 
1970 decisions led to scarce memory and as this is changed, so 
should the performance, 


increase capabilities, 


4, Form an MPE 3 group responsible for enhancements to the present 
MPE File System, 


5. Form an MPE 4 group responsible for "look ahead" projects such 
as re-writing the file system and restructuring the operating 
systen, 


a 


Ann Minzer 
Metropolitan State College Student 
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Mr. J. Alderete, a HP Project Manager, identified three specific areas of data 
communications currently being developed by HP. He also made note that the 
projects he would be discussing are not in production but are in the develop- 


mental stage only. 


The three general areas are: 

1.) An intelligent controller program 
2.) IBM data communications 

3.) HP networks 


The first concerns a mirco-processor based, intelligent data communications 
controller, specific benefits of the input/output subsystem would be: 

1.) Reduce CPU overhead 

2.) Simple extension 

3.) Supportability 


4.) Diagnostic capabilities 


New IBM system support was the second announcement. Interactive communication 
with the IBM host are to be improved by: 

1.) Improving console message handling 

2.) Making job submission more flexible 


3.) Expanding output 


Benefits of these efforts are to be realized in the area of distributed data 


base management, especially inventory control. 


The third area invloves standardization of the data communications within HP 
networks. Extensive polling of HP users and HP management will be necessary 
to develop such a system. Three specific advantages of the above efforts were 
mentioned. 

1.) Packet switching 

2.) Use of A,T and T's Advanced Communication Service 


3.) Satillite communication 


Questions were mostly on IBM data communications. Remote Job Entry and 
Multiple Remote Job Entry were discussed extensively. RJE through an IBM 
2780 Data Transmission Terminal or 3780 Data Communication Terminal was 


compared to MRJE. 


One-way protocall, limited compression, and limited console features were some 
of the drawbacks of RJE. MRJE, a more powerful full duplex line, offers a 


possible line cost advantage, has high compression, and a live console. 


In response to other questions: 
1.) MRJE is to be enhanced later through the CLP (6 months to a year). 
2.) MRJE is a high overhead feature as compared to a RJE system. 


3.) Data Systems Inc. is working on a dial up line for transmission within 
an HP group. 


4.) MRJE will not,support RES efficiently. 

5.) The CLP will eliminate 10 percent of CPU overhead. 

6.) Asynchronous transmission is not yet being developed. 

7.)  X-25 status is currently being developed in Europe. 

8.) MTS currently supports 14 terminals on one site. Possible release soon. 


9.) Nothing is currently being done to adapt peripherals to new HP 3000 
system 3. 


Comments: 


Content of the round table soon became too envolved for over half of partici- 
pants who left at various times throughout the block. Definition of the subjects 
to be covered were wholly misunderstood as beneficiaries of the discussion 


were confined to those with an extremely advanced knowledge of the material. 


Craig Morris 
Metropolitan State College 


[T-15 


This is a summary of the special “Round Tables" session, 
Machine Utilization: System Monitoring and Tuning Performance 
Measurement Tools, held on November 2, 1978, at the 7th 
International Meeting of the Hewlett Packard General System 
Users Group. 


The session was moderated by Tom Rawson of the University 
of Washington. Two HP lab persons Roy Clifton and Ken Spalding 
were in attendance, and addressed questions and topics which 
were brought up. 


The purpose of the session was to give feedback to HP as 
to what kinds of things are available, mainly in the Contributed 
Library, that the users would like to see HP produce. 


Reference was made to the paper in the proceedings by 
Jim Squires and Ed Splinter, System Performance Measurement and 
Optimization, and the following tools were mentioned and 
described: 


1) MONITOR A major tool provided by HP which is part of 
the operating system of the Series I, II, 
and III HP3000. The system activities are 
recorded and a window of that period is 
chosen for analysis which provides 
information concerning resource utilization, 
system workload and the programs used. 
Available only to SEs. 


2) TUNER2 Provides a display of what the CST is doing, 
For use with MPEII and MPEIII. In the 
Contributed Library. 


3) S00 For use with MPEII. Has a bug when used 
(SON OF with MPEIII. To correct it, one must set 
OVERLORD) the define statement with PCB entries to 


what is needed. In the Contributed Library. 


x 
4) SHOWVM Gives a snapshot,virtual mem ry to show 
how much memory the MPE is using. [In the 
Contributed Library. 


5) SHOWPIE Shows processes and what the system is 
doing. In the Contributed Libary. 


6) SHOWQO An MPE command provided by HP which lists 
all processes in the system as dormant, 
waiting or running. 


7) 


IDLE/ IDLE Used to show how busy the CPU is hourly. 

PRINT Some problem exists in that it gets 
itself in EM and should be in priority 
254. In the Contributed Library. 


8) OVERLORD For use with MPEIII. Does not give CPU 
percentage as doesSoOo. 
9) DREEACTG Thirty to forty programs in FORTRAN 


and SPL which analyze the log file to give 
information concerning system use. In the 
Contributed Library. 


Additional tools that were addressed were SAMPLER and 
TRACER, which will probably be available late next year and 
are expected to provide more evaluation at the application 
level than MONITOR, such as ségment histograms. 

SAMPLER presently will require the use of an additional 
Clock board. 


It was stated that one of HP's objectives is to produce 
tools to be sold to users which the users can use themselves, 
and thetHP wants to know what information the users need. 

The following user desires were expressed: 


1) 


2) 


3) 


4) 


5) 


6) 


7) 


8} 


That each district office should have a clockboard 
to rent to users who wish to use SAMPLER. 


Tools that the user can use without having to go to 
his SE every time. 


User does not want an SE in his system because of 
classified material. 


Would like to see something from HP like SOO, and 
does not want to have to go to an SE every time something 
goes wrong. 


Would like to see a CPU utilization guage in the 
HP3000. 


A set of tools to measure user running time to give 
him a histogram of what the user is doing. 


Wants MONITOR to be broken down into separate tools 
so that he can choose what: information he needs. 


A need to give the operator better control of the system: 
a) The ability to suspend sessions in order to get 
the system out of thrash. 


b) The ability to change the subqueues. 
c) The ability to alter priorities. 
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9) A tool to tune an application program when developing 
a system: 


a) To determine how the program is written affects 
usage time. 

b) To determine what is affecting performance. 

c) To give information on segmentation vs. design 
efficiency. 


10) To be able to change queves according to the time of 
day because certain users use the system at the same 
times each day. 


11) Wants segmentation information provided for FORTRAN 
programmers to improve program performance. 


12) Wants to see who is running what, how much CPU time 
is being used, and where a job is in the system. 


13) Wants snapshots of memory over periods of time. 

14) Wants HP to provide some configuration guidelines. 

The most generally agreed upon desires of the users seemed 
to be for tools that the users can use themselves which will not 


require any additional hardware, and for the provision of some 
basic configuration guidelines. 


By David Schwaab 
Metropolitan State College 
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BROWN DANA 
BROWN EDWIN J 
BROWN ROBERT A 
BRUCE CLIFF 
BRUNK GREGG A 
BRYDEN WILLIAM 
BRYSON GARY J 
BUELL DIANE 
BUTLER KEITH € 
BUTLER STEPHEN 4 
BYFORD WENDY K 
CALLANAN BILL 


CAMARILLO MARIO R 


CAMERON LOUISE 
CANTWELL FRANK E 
CARLSON LEE A 
CARR CHARLES E 


CARRUTHERS ALEX R 
CARVALHO MARCOS A X 


CASEY CHRIS J 
CAYLOR LARRY W 
CELLT JOHN 


CHADWICK GRAHAH D 


CHARD MILES M 
CHASE LARRY i 


SYSTEMS PROGRAMMER 
PROJECT MANAGER 


SYSTEMS ANALYST 
PROGRAMMER/ANALYST 
DIRECTOR DATA PROC 
SUPT MATERIALS 


DIRECTOR INFO SYSTEMS 
MGR SUPPORT SERVICE 


PRESIDENT 

DIR OF INST RESEARCH 
ADMINISTRATOR INFO 
PRESIDENT 


STANDARD OIL COMPANY 
JOHN HENRY COMPANY 
BROOKEHAVEN NATL LABOR 
BCS 

AUTOMATED ANALYSIS 
BALTIMORE GAS & ELEC 
HEWLETT-PACKARD SRD 
THE GAP STORES INC 


ADDRESS 


ONE EMBARCADERO CNTR 

{ BANKERS TRUST PLAZA 
COLUMBIA RD 

S675 ARAPAHOE 

395 DE MAISONNEUVE BLVD 
FIRST FINANCIAL TOWER 
S303 STEVENS CREEK BLVD 
iS VERBENA AVENUE 

{04 W PROSPECT AVENUE 

P QO BOX 17099 

32 BROOKERAVEN AVE 

PO BOX 24346 

Si0S DONA SOFIA DRIVE 
BOX 1475 

£400 FOUNTAIN GROVE PK 
900 CHERRY AVE 


GEORGE WASHINGTON UNIVERSI 725 23 STREET Ne 
£0030 407TH ST 7TH ST PLAZA EDMONTON 


SYNCRUDE CANADA LTD 
MARY WASHINGTON CLG 
SPRECKELS SUGAR DIV 
SYNCRUDE CANADA LTD 
BRANT COMPUTER SERVICES 
IND PRESS-TELEGRAM 
WESTINGHOUSE ELEC CORP 
SYNCRUDE CANADA LIMITED 
NICE CORPORATION 

MARY WASHINGTON CLG 

EB] COMPANIES 

WOOD BROWN & ASSOCIATES 


DATA PROCESSING SYSTEN M B.K. SWEENEY HAN, CO. 


D P ASST MANAGER 
ADMINSTRATIVE ASSISTANT 
PRESIDENT 

CONSULTANT 
ANALYST/PROGRAHHER 
ENGINEER 


DIRECTOR DATA PROCESSING PARADISE VALLEY HOSPITAL 


SYSTEMS ENGINEER 

S E SUPERVISOR 

DIR DE SISTERAS 
PROGRAMMER 

DIRECTOR PRODUCT DEV 


SAN JOSE MERCURY-NEWS 
HOUSTON INSTRUMENT 


INLAND SYSTEMS ENGINEERING 


SYSTEM HOUSE 
AURORA PUBLIC SCHOOLS 
HEWLETT-PACKARD 


HP 

HEWLETT-PACKARD LTD 
INFORMATICA DESC, SC 
DEPT REG ECO EXPANSION 
EPSILON DATA MGMT 


PROF MATH & COMP SCIENCE VALPARAISO UNIVERSITY 


MAN ANALYST PROG ITI 
SYSTEMS ENGINEER 
SYSTEMS ANALYST 

SYSTEMS SUPPORT HGR 
DATA PROCESSING HANAGER 
BUS & MKTING DEV HGR 
COMPUTER MANAGER 

DATA PROCESSING MANAGER 
SUPV SYS & PROGH 


SANGAMON STATE UNIVERSITY 


HEWLETT-PACKARD 
PROMON ENGENHARIA S A 
HEWLETT-PACKARD 
JOHANSON DIELECTRICS 
HEWLETT-PACKARD 

DE ZOETE D BEVAN 
CLA-VAL CO 

MULTNOMAH COUNTY ESD 


P O BOX 1081 CLG STAT 
50 CALIFORNIA ST 

PO BAG 4009 

615 BRANT STREET 

604 PINE AVE 

PQ BOX 8839 

{0030 407TH STREET 
4357 AIRPORT PARK PLAZA 
PO BOX 4081 CLG STAT 
1290 NORTH FIRST ST 
1673 CARLING AVE 

6300 STAPLETON S. DR. 
750 RIDDER PARK DR 
8500 CAMERON ROAD 


560 ROCHESTER 

1085 PEORIA STREET 

RT 44 & STAR ROAD 
2400 € 4TH STREET 

275 HYMUS BLVD 

KING ST LANE WINNERSH 
THIERS 248 ANZUREZ 
200 RUE PRINCIPAL 

24 NE EXECUTIVE PK 


ACADEMIC COMPUTER CENTER 


SHEPHERD ROAD 

210 7220 FISHER ST 
NOVE DE JULHO 4939 
{501 PAGE HILL R&D 
2210 SCREENLAND DRIVE 
5303 STEVENS CREEK 
THROGHORTON STREETS 
PO BOX i325 

220 SE 102 


ATTENDEE BY NAHE 


CITY STATE ZIP COUNTRY 


SAN FRANCISCO CA 94411 USA 


NYC 
MORRISTOWN 
BOULDER 
MONTREAL 
TAMPA 
SANTA CLARA 
FLORAL PARK 
CLEVELAND 
LANSING 
UPTON 
SEATTLE 
STUDIO CITY 
BALTIMORE 
SANTA ROSA 
SAN BRUNO 
WASHINGTON 


FREDERICKSBUR 


NY 40006 USA 
NJ 07960 USA 
CO 90303 USA 
QU J6K2E CANADA 
FL 33614 USA 
CA 95050 USA 
NY 11004 USA 
OH 44115 USA 
HI 48984 USA 
NY 141973 USA 
WA 98124 USA 
CA 91604 USA 
HD 24203 USA 
CA 95404 USA 
CA 94066 USA 
DC 20052 USA 
AL TSJ3ES CANADA 
VA 22401 USA 


SAN FRANCISCO CA 94411 USA 


FT MC MURRAY 


AL T9H2Li CANADA 


BURLINGTON ON L7R2G6 CANADA 
LONG BEACH CA USA 
PITTSBURGH PA {S2ei USA 
EDMONTON AL TSJ3ES CANADA 
ODGEN UT 84403 USA 
FREDERICKSBUR VA 22401 USA 
SAN JOSE CA 95if2 USA 
OTTAWA ON K2AiC4 CANADA 
DENVER CO 80216 USA 
SAN JOSE CA 95190 USA 
AUSTIN TX 78753 USA 
REDLANDS CA USA 
OTTAWA ON KiB3BB CANADA 
AURGRA CO 80011 USA 
AVONDALE PA 19314 USA 
NATIONAL CITY CA 92050 USA 
PTE CLAIRE QU CANADA 
WOXINGHAH BER ENGLAN 
REXICO DF MEXICO 
HULL QU KiAOH4 CANADA 
BURLINGTON MA 01803 USA 
VALPARAISO IN 46383 USA 
SPRINGFIELD IL 62708 USA 
CALGARY AL T2H2HB CANADA 
SAD PAULO SP 01407 BRAZIL 
PALO ALTO CA 94384 USA 
BURBANK CA 91585 USA 
SANTA CLARA CA 95050 USA 
LONDON ENGLAN 


NEWPORT BEACH CA 92663 USA 


PORTLAND 


OR 97216 USA 


NAME-2 


NAKE 


CHATFIELD DENNIS C 
CHEN CHANG L 
CHITWOOD RICK L 

CHIU WUYAN 
CHRISTOPHERSON DIANE 
CLABORN GEORGE H 
CLARK KIM 

CLEEVER KAREN J 
CLEMENT RUBY J 


TITLE 


SYSTEM MANAGER 
SYSTEM ANALYST 
ASST V P INFO SYS 
PROJECT ENGINEER 


PROGRAMMER ANALYST 


SYSTEMS PROGRAMMER 
DIRECTOR OF DP 


CLEMENTSON GERHARDT C DIR OF ACAD COMP CNTR 


CLEVELAND WALTER 
CLIFTON ROY A 
COLDREN J DAVID 
CONNOR JACK 

COOK LINDA L 
COOKSEY WILLIAM P 
COOPER PAUL D 
COOPER STEVEN # 
COPLIN ROBERT G 
CORDELLE YANN 
CORRELL STEVEN 
COUCH JOHN D 
COVITT HARC L 

COX W PHIL 
CRAWFORD JEFFREY D 
CROCKETT DAVID 
CROW WILLIAM 4 
CULPEPPER BRITTON B 
CURBELO RALPH 
CURRERT JOSEPH A 
CURTIS LINDA 
D’ANGELO RICHARD J 
DAILEY JOSEPH D 
DARN JACK A 
DAUGHERTY ROGER 
DAVISON GERALD W 
DAVY CHRIS 

DAVY CHRISTOPHER 
DEBOK LOWELL w 
DELHAGE A R(CANCELED) 
DELONG DAN G 
DEMEVSY JIM 

DINAN DENNIS ¥ 
DOLAN JR DOUGLAS C 
DONKAM DAN 

DOUGLAS GORDON R 
DOWLING JAMES F 
DREILING CHERYL 8B 
DROBNY RONALD G 
DRYRAN GILBERT W 
DUHAS ROBERT J 
DUMRER DAVID C 


MPE SUPPORT MANAGER 
ASSOCIATE DIRECTOR 
SR CONSULTANT 

DATA PROC SPEC/PRGHR 
PROGRANMER/ANALYST 
SYSTEMS ENGINEER 
CONSULTANT 

D P DIRECTOR 
ENGINEER 

ENGINEER 

SECTION MANAGER 
TECHNICAL SVCS NGR 
SYSTENS ANALYST 
PRESIDENT 


PRG HGR HP300 SYS 


HGR TECHNICAL SYSTEMS 
SYSTEMS ANALYST 
COST ANALYST 


ANALYST/PROGRAMMER 
SYSTENS ENGINEER 


HANAGER DATA PROCESSING 


PRINCIPAL/OUNER 


COMPANY 


R J FRISBY 

HP AVONDALE DIV 

UNTTED PRESIDENTIAL LIFE 
BOEING COMM AIRPLANE CO 
UNIVERSITY OF WISCONSIN 
ENVIRONMENTAL ELEMENTS 
HC MASTER UNIVERSITY 


ADDRESS 


{500 CHASE 

ROUTE 44 & STARR RD 
217 SOUTHWAY BLVD E 
P Q BOX 3707 36-02 


3700 KOPPERS ST 
{200 MAIN STREET WEST 


DEPT REGIONAL ECONOMIC EXP 604 SPADINA CRES E 


UMPQUA COMM COLLEGE 
METROPOLITAN ST COLLEGE 
UNITED COMPUTING SYS 
HEWLETT-PACKARD 

TL LAW ENFORCEMENT CO 
SYSTEMS & COMP TECH 
ALLEGHENY INTER UNIT 
COPCO 

HEWLETT-PACKARD 


AMERICAN MANAGEMENT SYSTEM S61 PILGRIM DRIVE SUITE D 


CITY OF KENNEWICK 
COGELOG 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD SDD 
PROCTOR & REDFERN 
OMEGA SYSTEMS, INC. 
HEWLETT-PACKARD 
AUSTIN INFORMATION SYS 
UNION CAMP CORP 

NEW YORK TELEPHONE CO 


PETRO CANADA 
HEWLETT-PACKARD CO 
MASTERCRAFT IND 
THE PALO ALTO GROUP 


DIRECTOR DATA PROCESSING AMERICAN SUBSRIPT TV 


PROJECT MANAGER 
MANAGER 

PRODUCT MANAGER 
PROGRAMMER/ANALYST 


PROGRAMMER 


ARGONNE NATIONAL LAB 
KEYDATA CORP 

KEYDATA CORP 

MITCHELL BROS TRUCK 
GOV'T OF NW TERRITORIES 
FEDERAL HOME LOAN BANK 
SILTON DATA INC 


SENIOR PROGRAMMER ANALYS MORGAN GUARANTY TRUST 


SPECIAL PROJECTS HER 
SYSTEMS ENGINEER 
FACILITY INFO SYS MER 
DP OPERATIONS MANAGER 
COMPUTER SCIENTIST 
SYSTEM MANAGER 
SYSTEHS DEV MANAGER 
MARKETING SUPPORT 
PRESIDENT 


VICTOR O SCHINNERER 
HEWLETT-PACKARD 
HEWLETT-PACKARD 

BOSE CORPORATION 
LAWRENCE LIVERMORE LABOR 
GATES & SONS 

BOEING AEROSPACE CO 
SYSTEMS RESEARCH INC 

D C DUMMER & ASSOCIATES 


P 0 BOX 967 

{006 44TH STREET 

2525 WASHINGTON 

972 BUCKEYE CT 

120 S RIVERSIDE PLAZA 
7.N 5 POINT RD 


SUITE 300 TWO ALLEGH CENTER PITTSBURGH 


4905 LIMA STREET 
4110 S 400 E AVE 


210 W OTH 

{ QUINCONCES 

RT 41 & STAR ROAD 
5303 STEVENS CREEK 
163997 W BERNARDO DR 
75 EGLINTON AVE E 
5720 SO ROCKWELL ST 
5303 STEVENS CREEK 
450 WEST {ST AVENUE 


1095 AVE OF THE AMERICAS 
9142 EDMONSTON CT 202 
P 0 BOX 2844 

Se HARTWELL AVE 

4881 IRONTON ST 

790 LUCERNE DRIVE 

8383 WILSHIRE BLVD 
9700 SOUTH CASS AVENUE 
1400 WILSON BLVD 

4400 WILSON BLVD 

3844 N COL BLVD 


600 STEWART ST 

2407 E 38TH STREET 

23 WALL STREET 

S028 WISCONSIN AVE NW 
5600 DIC PKWY 

11000 WOLFE ROAD 

100 MOUNTAIN ROAD 

P Q BOX 808 

90 SCUTH FOX 


PQ BOX 3999 


2400 SCIENCE PARKWAY 
40 LK LUCERNE CL SE 


ATTENDEE BY NAME 


CITY STATE ZIP COUNTRY 


ELK GROVE TL 60007 USA 
AVONDALE PA 19341 USA 
KOKOMO IN 46904 USA 
SEATTLE WA 98124 USA 
RIVER FALLS WI 54022 USA 
BALTIMORE HD 24227 USA 
HAMILTON ON L8S439 CANADA 
SASKATOON SA S7KIG8 CANADA 
ROSEBURG OR 97470 USA 
DENVER CO 80264 USA 
KANSAS CITY HO 64108 USA 
SUNNYVALE CA 94086 USA 
CHICAGO TL 60606 USA 
WEST CHESTER PA 49380 USA 
PA iS2i2 USA 
DENVER CO 80239 USA 
TULSA OK 7444S USA 
SAN MATEO CA 94404 USA 
KENNEWICK WA 99336 USA 
GIF 91190 FRANCE 
AVONDALE PA 19311 USA 
SANTA CLARA CA 95050 USA 
SAN DIEGO CA 92127 USA 
TORONTO ON KAPSH3 CANADA 
CHICAGO IL 60632 USA 
SANTA CLARA CA 95050 USA 
ROSELLE NJ 07203 USA 
FRANKLIN VA 23851 USA 
NEW YORK NY {0036 USA 
GREENBELT MD 20770 USA 
CALGARY AL TéP2H7 CANADA 
LEXINGTON HA 02173 USA 
DENVER CO 80239 USA 
SUNNYVALE CA 94086 USA 
BEVERLY HILLS CA 902{4 USA 
ARGONNE TL 60439 USA 
ARLINGTON VA 22209 USA 
ARLINGTON VA 22209 USA 
PORTLAND OR 97217 USA 
YELLOWKNIFE © NW XOE{HO CANADA 
SEATTLE WA 98101 USA 
VERNON CA 90658 USA 
NEW YORK NY 10045 USA 
WASHINGTON DC 20046 USA 
ENGLEWOOD CO 80119 USA 
CUPERTINO CA 95014 USA 
FRAMINGHAM MA 01704 USA 
LIVERMORE CA 94556 USA 
DENVER CO 80226 USA 
SEATTLE WA 98124 USA 
OKEHOS HI 48864 USA 
CALGARY AL T2J3HS CANADA 


NAHE-3 


NAHE TITLE 
DUMMER SHEILA T MANAGER FINANCIAL SYSTEM QUME CORP 
DUNCAN HANNAH F 
DUNCAN JAKES J MANAGER OEM SALES 
DUNCOMBE BRIAN C 
DURHAM PAUL H SYSTEMS ANALYST PROG 
EARLS JOHN D STAFF ENGINEER 
EATON JOHN DIR COMPUTER SERVICES 


ECCLES SHARON L DATA PROCESSING MANAGER 


ECKARD DAVID L SYSTEM ANALYST 


EDWARDS BETH INFO SYSTEMS ADH 
EDWARDS CONSTANCE E MANAGER COMPUTER CTR 
EDWARDS JON L 

EDWARDS ROBERT # SPEC ASST FOR DP 


ELLIOTT HARRY A MANAGER MIS DEPARTMENT 


ENGBERG TONY I SYSTEMS ENGINEER 
ENGLANDER ALICE D P CONSULTANT 
ENGLANDER WILLIAM R 9} P CONSULTANT 
ENGLEBRECHT MICHAEL L RESEARCH ENGINEER 
ENTIS GLENN Mi PROGRAMMER ANALYST T 
ERICSCON GORDY 0 ANALYST 

EXCOFFON MARGOT M = =s-s PROJECT LEADER 
FAIRCHILD JAMES B SUPERVISOR OPERATIONS 
FAIRFIELD STEVE INFO SYSTEMS ANALYST 


FARIA JOHN MGR COMPUTER SERVICES 


FARKAS GEORGE J SYSTEMS ANALYST 
FARRAGHER MICHAEL J PROG SUPERVISOR 


FARRELL JIM G DIRECTOR MARKET RESEARCH WM C BROWN PUB CO 
FAWKES GERALD PROGRAMMER 

FEHR GENE I D P MANAGER 

FELDMAN DAN 

FERENSEN DANIEL E © SYSTEMS ANALYST 

FIELDS JAMES A VICE PRESIDENT 

FIGUEROA LUIS ¥ CTE DE PROCESAMIENTO 
FINE BRIAN T TECH STAFF 

FINNEY BILLTANNA N = PROGRAMMER 

FISCHER LEE H MANAGER DATA PROCESSING 
FISHER M ROGER MANAGER COMPUTER SERV 
FLEET VICTOR W CONTRGLLER 

FLOWERS CURTIS J DP ANALYST IT 

FLOYD TERRY H ACCNT SYSTEMS ANALYST 
FLYNN DOUGLAS C D P MANAGER 

FORSEE ANN T INSTRUCTOR 

FOSTER RICHARD 4 MANAGER SYSTEM 5/W 
FRAGH EDWARD A SYSTEMS & PROG SUPVSR 
FRANE DARYL A SYSTEM MANAGER 


FRANSEN CRAIG 5 SYSTEM ANALYST 
FRASER TOM 

FRATUS WILLIAM P 

FRECH JOHN J MANAGER OF STIC 
FREDRICKSON GUNNARD A PROJECT LEADER 
FREDRICKSON STEVE DISTRICT SALES HGR 


2323 INDUSTRIAL PARKWAY 
{601 LEHMBERG BLVD 
KAPPA SYSTEMS INC 


PETRO CANADA INC 
ARTHUR A COLLINS INC 
LONDON BUS SCH GRAD STUDIES 


{3604 PRESTON ROAD 


WESTINGHOUSE ELEC € 
EDWARDS BENJAMIN E ASST MGR DATA PROCESSING UNION CAKP CORP 

GENERAL TELEPHONE-HI 

ST FRANCIS XAVIER UNIV 
JENNISON ASSOCIATES 

NATL CONF ST LEGISLATURES 
THE CANADA STARCH CO 


455 € ELLIS ROAD 
PO BOX 67 ST.F.X.U. 


444 N CAPITOL ST WW 

i PLACE DU COMMERCE 
19855 GIESENDORFER &D 
1966 TITUS STREET 
{966 TITUS STREET 

703 CURTIS STREET 


WILLIAM R ENGLANDER 


MORGAN GUARANTY TRUST 
3M CENTER BLDG 224-4N 
LYNES UNITED SERVICES 
DOMTAR INC CHEM GROUP 
GENERAL TELEPHONE 
PRUDENTIAL REINSURANCE 
CHRYSLER CORPORATION 


455 E ELLIS ROAD 

213 WASHINGTON ST 

PO BOX 4949 CINS: 4462725 
475 WYMAN STREET 

2460 KERPER BLVD 

DEPT OF FISHERIES & QCEANS BRANDY COVE 

COHEN FURNITURE CO 336 SW ADAMS STREET 
ADRIA LABORATORIES 
APEX DATA PROCESSING 
EJES TRACTIVOS SA 


950 SO EASTERN AVE 
APARTADO POSTAL 14820 


75 COROHAR DRIVE 
2323 INDUSTRIAL PARKWAY 


SANTABARBARA RESEARCH 


ENVIRONMENTAL ELEMENTS 
B&S FINANCIAL SERVICES 
SANGAMON STATE UNIV 


N COUNTY ROAD 25A 


LEXINGTON HERALD LEAD 239 WEST SHORT ST 
ANDERSON COLLEGE 
SYSTEM DEVELOPMENT CORP 


CITY OF SANTA MONICA 


2500 COLORADO AVENUE 
1685 MAIN STREET 

227 W HUENEME ROAD 
SYSTEMS RESEARCH INC 2400 SCIENCE PARKWAY 
ADRIA LABORATORIES 


RELIANCE ELECTRIC 
UNITED COMPUTING SYS 


150 CANTERBURY DR 
4544 POST OAK PL 


ATTENDEE BY NAME 


CITY STATE ZIP COUNTRY 


HAYWARD 


HAMILTON 
CALGARY 
DALLAS 
LONDON 


MENLO PARK 
PHILADELPHIA 


FRANKLIN 
MUSKEGON 


ANTIGONISH 


NEW YORK 


WASHINGTON 
NUNS? ISLAND 


COLFAX 


SAN DIEGO 
SAN DIEGO 
HIDDLETOWN 


NEW YORK 
ST PAUL 
CALGARY 
MONTREAL 
MUSKEGON 
NEWARK 
DETROIT 
WALTHAH 
DUBUQUE 


ST ANDREWS 


PEORIA 


WATERTOWN 


COLUMBUS 


LOS ANGELES 


MEXICO 


SUNNYVALE 


GOLETA 
HAYWARD 


BALTIMORE 


PIQUA 


SPRINGFIELD 
SAN MARCOS 
LEXINGTON 


ANDERSON 


CA 94545 USA 
COLORADO SPRI CO 8071S USA 
COLORADO SPRI CO 80909 USA 
ON LON3T2 CANADA 
AL T2P2H7 CANADA 


TX 75240 
EN 
CA 
PA 19413 
VA 23851 
MI 49443 


USA 
ENGLAN 
USA 
USA 
USA 
USA 


NS B2GiC0 CANADA 


NY 40047 
DC 2000! 


USA 
USA 


QU H3ELA7 CANADA 


CA 95715 
CA 92110 
CA 92410 
OH 45043 
NY 10045 
MN SS5i0f 


USA 
USA 
USA 
USA 
USA 
USA 


AL T2POCS CANADA 
QU H3C3M3 CANADA 


HI 49443 
NJ 07101 
MI 48288 
MA 02154 
IA Se0di 


USA 
USA 
USA 
USA 
USA 


NB E0G2X0 CANADA 


IL 61602 
MA 02172 
QH 43216 
CA 90022 
DF 14820 
CA 94086 
CA 93017 
CA 94545 
HD 21227 
GH 45356 
IL 62708 
TX 78666 
KY 40507 
IN 46041 


SANTA HONICA CA 90406 


OXNARD 
TACOMA 
OXEMOS 
AUSTIN 
COLUMBUS 
ATHENS 
HOUSTON 


CA 93030 
WA 98404 


MI 48864 


TX 78704 
OH 43216 
GA 

TX 77027 


USA 
USA 
USA 
USA 
MEXICO 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 


SANTA MONICA CA 90401 USA 


USA 
USA 
USA 
USA 
USA 
USA 
USA 


NAKE-4 


RAKE 


FREED JANES F 
FRENCH DEBORAH J 
FRYER WILLIAM R 
FUNK CHRISTOPHER 4 
GALLARDO PEDRO A 
GALUSKY DIANE ¥ 
GARDINER JAMES A 
GARDNER LYNN 
GATES BILL 

GEER ROSS E 
GENTRY THOMAS L 
GEWECKE JOHN W 
GEYER SANFORD A 
GILCHRIST DON 
GILL RICK 

GIMPLE BILL 
GLOSS GREGORY C 
GOJENOLA BEN 
GOLDBERG MICHAEL C 
GOLDMANN ROGER H 
GOMEZ VICTOR 
GOODMAN ROBERT A 
GOOLSBY MONTY P 
GORFINKEL MARTIN 


GOSSELIN JEANNINE G 


GOT TERRENCE 
GRACE JAYNIA 
GRADY MICHAEL K 
GREEN ANNABELLE H 
GREEN CHARLES R 
GREEN ROBERT 4 
GREENE MARK L 
GREGORY KENT A 
GRICE FRANK H 
GRIFFIN MARY 
GRIFFIN RICK 
GRILLOS JOHN 4 
GROFF JAMES R 
GROSSCUP LORIN 
GRUBER DIANNE 
GUERRERO JORGE 
GUISINGER ERIC L 
GULICK LLOYD R 


GUNBY D L (CANCELED) 


GUPTA RAMESH 


GURUPRASAD CHOULGERE 


GHALTHNEY DAVID L 
HACKHAN LINFORD B 
HAINES OLIN R 
HAISCH KEN R 

HALL CRAIG T 
HALLOCK JIM 


TITLE 


INFO SYSTEMS MANAGER 
PROGRAMMER/ANALYST 
PRESIDENT 

PRESIDENT 

SYSTEM ENGINEER 
SUPERVISOR APPL DEV 
MIS MANAGER 

CUSTOMER RELATIONS 
DATA PROCESSING HGR 
DIRECOTR OF SYS ENGR 
HGR ENG’G COMPUTER CTR 
DISTRICT SALES HER 
SYSTEM MANAGER 


SYSTEMS ANALYST 


R & D MGR HP300 PRG 


COBOL PROJECT MANAGER 
OR SOFTWARE DESIGNER 
PRESIDENT 

SYSTEMS ANALYST 
SYSTEM ENGINEER 
PRESIDENT 

SYSTEMS MANAGER 
PARTNER 

EDP MANAGER 

D P MANAGER 


SYSTEMS CONSULTANT 
SECRETARY/TREASURER 


DATA PROCESSING MANAGER 


PRESIDENT 
SUPERVISOR 

ACTUARY /PROGRAMMER 
PRESIDENT 
MARKETING ENGINEER 
PRESIDENT 

VICE PRESIDENT 
PRODUCT MANAGER 
PROGRAMMER 


§ £ INSTRUCTOR 
PROGRAMMER/ANALYST SR 
COMPUTING SPECIALIST 


COMPANY 


HEWLETT-PACKARD 
HEWLETT-PACKARD 
5.B.D.P. 

C WM FUNK & CO INC 
UNIVERSIDDO BAJA CAL 
HUGHES AIRCRAFT CO 
PILKINGTON BROS 
HEWLETT-PACKARD 

LONGS DRUG STORES, INC 
TEXAS MUN POWER AGENCY 
MICROWAVE ASSOCIATES 
UNITED COMPUTING SYS 
ROLM CORP 

NC MASTER UNIVERSITY 
VANDERBILT UNIVERSITY 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
WEYERHAEUSER CO 


FINANCIAL DATA PLANNING 


COMARCO INC 
ELECTRONIC DATA SYS 
PROF COMP SERV 
UNION CAMP CORP 


LOS ALTON RESEARCH CENTER 


DOMTAR INC CHEM GROUP 
SAN JOSE MERCURY-NEWS 
UNITED COMPUTING SYS 


ILLINOIS DEPT LAW & ORDER 


ROBELLE CONSULTING LTD 
ADAMS COUNTY SCHOOLS 
ROBELLE CONSULTING LTD 
3K CO 

ZISCHKE ORGANIZATION 
INTERTEC 
HEWLETT-PACKARD 

TC S SERVICES, INC 
AMERICAN MGMT SYSTEMS 
HEWLETT-PACKARD 
MERCHANDISING METHODS 
HEWLETT-PACKARD 
HEWLETT-PACKARD 

KAISER FOUNDATION 
HUGHES AIRCRAFT CO 


SUPV SYSTEM DESIGN & PRO BONAR & BEMIS LTD 
SYSTEMS & OR CONSULTANT DOMTAR INC CHEM GROUP 


DIRECTOR CORP SYSTEMS 
DIRECTOR-CCIS 
ADMIN SOFTWARE HGR 


DATA PROCESSING MANAGER 


PRESIDENT 
PRESIDENT 


DEPT OF SUPPLY CANADA 
RUTGERS UNIVERSITY 
VYDEC INC 

WICHITA EAGLE & BEACON 


ADDRESS 


ROUTE 41 
3400 E HARMONY ROAD 
4208 AIRPORT ROAD 


2 N eND STREET BOX 1249 


OBREGON Y F C CALCOLO 
P 0 BOX 3310 607/E334 
685 WARDEN AVE 


5303 STEVENS CREEK BLVD 


144 NORTH CIVIC DR 
2225 E RANDOL MILL RD 
SOUTH AVE 

4904 AVE OF STARS 
4900 OLD IRONSIDES DR 
4200 HAIN ST WEST 
S24 KIRKLAND HALL 
5303 STEVENS CREEK 
5303 STEVENS CREEK 
{0TH & A STREETS 
2670 TIGERTAIL AVENUE 
227 W HUENEME ROAD 
ONE WAYNE MALL 

e821 E 28TH STREET 
PQ BOX 570 


339 S SAN ANTONIO ROAD 


BP 72i2 

750 RIDDER PARK DR 
e525 WASHINGTON 

200 W WASHINGTON 
#130-5421 410TH AVENUE 
602 E 64TH AVE 
$130-5421 10TH AVENUE 
SM CENTER BLDG 224-4N 
4 POST STREET 

2625 PARK BLVD 


$303 STEVENS CREEK BLVD 


ei3i W EULESS BLVD 


S61 PILGRIM DRIVE SUITE D 


{342 STAYNER RD 

274 BRANNAN STREET 
{900 GARDEN GODS ROAD 
4 CHOKE CHERRY RD 
2005 FRANKLIN ST 

PO BOX 3340 607/£334 
2s80 MC DOWELL ROAD 
BP 72i2 

11 LAURIER 

Sii N FIFTH STREET 

7 VREELAND ROAD 

825 E DOUGLAS 


CASCADE COMPUTER SYSTEMS I P OQ BOX 1666 


INFO TRONIC SYSTEMS 
HEWLETT-PACKARD 


449 HOWARD AVE 
B15 14 SW 


$585 


RMB-2 


ATTENDEE BY NAME 


CITY STATE ZIP COUNTRY 


AVONDALE PA 19311 USA 
FORT COLLINS €O 80525 USA 
CINCINNATI OH 45226 USA 
LAFAYETTE IN 47982 USA 
MEXICALI MAJA MEXICO 
FULLERTON CA 92634 USA 
SCARBOROUGH ON MiL3Z8 CANADA 
SANTA CLARA CA 95050 USA 
WALNUT CREEK CA 94596 USA 
ARLINGTON TX 760441 USA 
BURLINGTON MA 041803 USA 
LOS ANGELES CA 90067 USS 
SANTA CLARA CA 95050 USA 
HAMILTON ON L8S4J9 CANADA 
NASHVILLE TN 372355 USA 
SANTA CLARA CA 95050 USA 
SANTA CLARA CA 95050 USA 
TACOMA WA 98401 USA 
MIAMI FL 33433 USA 
OXNARD CA 93030 USA 
WAYNE NJ 07470 USA 
LONG BEACH CA 92648 USA 
SAVANNAH GA 31402 USA 
LOS ALTOS CA 94022 USA 
NONTREAL QU HSCSMS CANADA 
SAN JOSE CA 95190 USA 
KANSAS CITY 0 64408 USA 
SPRINGFIELD = IL USA 
DELTA BC V4M3T9 CANADA 
DENVER CO 80229 USA 
DELTA BC V4N3T9 CANADA 
ST PAUL MN S5i0i USA 
SAN FRANCISCO CA 94404 USA 
PALO ALTO CA 94306 USA 
SANTA CLARA CA USA 
EULESS Tk USA 
SAN MATEO CA 74404 USA 
SAN JOSE CA 95i2i USA 
SAN FRANCISCO CA 94107 USA 
COLORADO SPRI CO 80967 USA 
ROCKVILLE MD 20850 USA 
DENVER CO 80205 USA 
FULLERTON CA 92634 USA 
BURLINGTON © ON L7R4AL CANADA 
MONTREAL QU HICSNS CANADA 
HULL QU CANADA 
CAMDEN NJ 08102 USA 
FLORHAM PARK NJ 07932 USA 
WICHITA KS 67202 USA 
LONGVIEW WA 98632 USA 
HOLLAND MI 49423 USA 
LOVELAND CO 80537 USA 


NAME-S 


NAHE 


HALSEY GREGG 
HAMAN VINCE J 
HAMPTON JEAN K 
HANSEN WILLIAM R 
HANSON FRITZ ¥ 
HARBAUGH JERRY E 
HARBRON THOMAS R 
HARMAN LAWRENCE K 
HARRIS DAVID W 
HATCH JAKES L 
HATCHER BETH 
HAUDERT GERARD A 
HAYS GARRY R 
HEDA SHARAD 

HEIN NORM 

HEINEN TERRY Hi 
HELLANS CAROLE 
HENRY WENDELL A 
HERBEL ERIC 5 
HICKS DAVID L 
HINES RELLA A 
HISKES GEORGE J 
HODSON DICK 

HOKE ROBERT D 


TITLE 


SYSTEM ANALYST 
DIRECTOR DP 
PROGRAMMER 

SR SYSTEM CONSULTANT 


COMPANY 


BOEING COMPUTER SERVICE 
JOHNSON COUNTY 
WH C BROWN PUB COMPANY 


LOGISTICS SYSTEM ENGINEE BOEING AERO SPACE CO 


MGR DATA PROCESSING 
CHR COMPUTER SCIENCE 
GROUP LEADER 

MANAGER 

DIRECTOR 


OPERATIONS SUPERVISOR 
SR DATA COMMUNICATION 
MANAGER ADM SYS 
MANAGER INFO SERVICES 
E D P MANAGER 

D P PROG ANALYST 
MEMEBERT OF TECH STAFF 
MEDICAL SYS ANALYST 
PROGRAMMER ANALYST 
EXECUTIVE DIRECTOR 


DATA PROCESSING HANAGER 


DP MANAGER 
MARKETING MANAGER 


HOLLING ERNEST(CANCEL)DIRECTOR-DATA SYSTEMS 


HOLMAN JAMES R 
HOLT WAYNE E 
HOUY DAVID J 
HUDSON MEL 
HUNTER JOHN C 


HUTCHINSON PHILIP L 


HUTTUNEN HEIKKI J 
HUXHAM BASIL C 
HUXHOLD PHIL W 
HWA CHIH § 

ICKLER AL 

IMBEAU ANDRE 
IRIYE DICK 

IZETT CRAIG N 
JACKSON CHARLES W 
JACKSON ELAINE T 
JACKSON JOHN A 
JACOB HARRY 0 
JAMES ROBERT Hi 
JAMISON CARL L 


JARAMILLO JR NARCISO 


JARVIS RAY D 
JEANS KENNETH E 


JEFFRIES WILLIAM F 


JELLIFFE ARLENE Hi 
JENSEN HAROLD E 
JESSEN TIM D 


HEAD STATISTICS LAB 
DIRECTOR OR D P 
FINANCIAL SYSTEMS HER 
SYSTEMS ANALYST 
SYSTEMS SUPERVISOR 
PRODUCT ENGINEER 

ADP MANAGER 


MANAGER DATA PROCESSING 


DP MANAGER 

PRESIDENT 

SENIOR PROGRAMMER 
ACTING CHIEF 
SYSTEMS ANALYST 
DIRECTOR TECHNOLOGY 
PRESIDENT 
MINICOMPUTER ANALYST 
SYSTEMS ANALYST 


MER DISTRIBUTED SYSTEMS 


ANALYST/PROGRAHKER 


DATA PROCESSING MANAGER 


DB ADMIN 

PRUGRAMMER 

ASST HGR OF DATA PROC 
COORDINATOR ICS 

LEAD ENGINEER 
SYSTEMS ANALYST 
COMPUTER SCIENTIST 


ELF AB 

ANDERSON COLLEGE 
LAWRENCE LIVERMORE LAB 
NBS FINANCIAL SERVICES 
GM SAGINAW DATA CENTER 
HEWLETT-PACKARD 
BROOKEHAVEN NATL LABOR 
UNION OIL CO 

VYDEC INC 

WH C BROWN PUB COMPANY 
ST CLOUD HOSPITAL 
WHARTON CO JR COLLEGE 
HEWLETT-PACKARD 
HOECHST-ROUSSEL PHARM 
PACIFIC MUTUAL 

HP GEN SYS USERS GROUP 
BEALL’S DEPARTMENT ST 
VALTEC 
HEWLETT-PACKARD 

STORER BROADCASTING 
OHIO AGRIC R&D CENTER 
WHITMAN COLLEGE 

SMITH INTERNATIONAL 
COLO DEPT OF EDUC 
OKANAGAN HELICOPTERS 
HEWLETT-PACKARD FCD 
HELSINKI SCHOOL OF ECON 
PORT OF VANCOUVER 
MERCHANDISING METHODS 
COMPUSYS INC 

COLO DEPT OF EDUC 
DEPT REG ECO EXPANSION 
BOETTCHER & CO 

MARTIN MARIETTA 
COLLIER-JACKSON ASSOC 
HARTFORD INSURANCE 
DOMINION CONSTRUCTION 
GH SAGINAW DATA CENTER 
SANDIA LABS 

CRAIG HOSP RESEARCH OFFC 
BOURNS 

UMPQUA DATA FACTORY 
NOOTER CORP 

STARK COUNTY DEPT ED 
BOEING COMM AIRPLANE CO 
WILLAMETTER VALLEY CO 
LAWRENCE LIVERMORE LAB 


ADDRESS 


P 0 BOX 24346 

P 0 BOX 2540 
2460 KERPER BLVD 
5569 CAMERFORD DR 


PO BOX 3999 


4200 WYLEY POST 


P 0 BOX 808 HC L-389 
S00 W WILSON BDG RD 
3900 HOLLAND ROAD 

5304 STEVENS CREEK BLVD 
32 BROOKEHAVEN AVE 

464 S BOYLSTON ST 

9 VREELAND ROAD 

2460 KERPER BLVD 

{406 6TH AVENUE NO 

911 BOLING HIGHWAY 

S303 STEVENS CREEK 

RT 202-206 NORTH 

700 NEWPORT CENTER DRIVE 
P 0 BOX 18813 

3923 MANATEE AVE W 

BOX 2200 

DISC MEMORY DIVISION 
1177 KANE CONCOURSE 


345 BOYER AVE 

4343 VON KARMAN AVE 
204 E COLFAX 

4394 AGAR DRIVE 
3400 E HARMONY RD 
RUNEBERGINK 14-16 
4300 STEWART ST 

274 BRANNAN STREET 
789 SHERMAN S60 

204 E COLFAX 

200 RUE PRINCIPAL 
828 {7TH STREET 

300 EAST JOPPA RD 
i805 N WESTSHORE BLVD 
HARTFORD PLAZA 

3i00 3 BENTALL CENTRE 
3700 HOLLAND ROAD 
P 0 BOX 5800 

3460 SO CLARKSON 
{208 COLUMBIA AVE 
727 SE CASS 

P 0 BOX 45i 

7800 COLUMBUS RD 
BOX 3767 

660 HC KINLEY 

P 0 BOX 898 L-414 


ATTENDEE BY NAME 


CITY STATE ZIP COUNTRY 


SEATTLE WA 98124 
IOWA CITY TA 52240 
DUBUQUE TA 52084 
DAYTON GH 45424 
SEATTLE WA 98124 
ADDISSON TX 75001 
ANDERSON IN 46044 
LIVERMORE CA 94550 
COLUMBUS OH 43285 
SAGINAW HI 48605 
SANTA CLARA CA 95050 
UPTON NY 11973 
LOS ANGELES (CA 90017 


USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 


FLORHAM PARK NJ USA 
DUBUQUE TA 52001 USA 
ST CLOUD MN S6301 USa 
WHARTON TX 77488 USA 
SANTA CLARA CA 95050 USA 
SOMERVILLE NJ 08876 USA 
NEWPORT BEACH CA 92660 USA 
BALTIMORE MD 24240 USA 
BRADENTON FL 33505 USA 
SPRINGVILLE UT 84663 USA 
BOISE TD 83707 USA 
BAY HARBOR IS FL 33454 USA 
WOOSTER QH 44691 USA 
WALLA WALLA WA 99362 USA 
NEWPORT BEACH CA 92660 USA 
DENVER CO 90203 USA 
VANCOUVER BC V7BiAS CANADA 
FORT COLLINS CO 80525 USA 
HELSINKI 004005 FINLAN 
VANCOUVER BC VSL4X5 CANADA 
SAN FRANCISCO CA 94407 USA 
DENVER CO 80203 USA 
DENVER CO 80203 USA 
HULL AU KiAQM4 CANADA 
DENVER CO 80202 USA 
BALTIMORE MD 21204 USA 
TAHPA FL 33607 USA 
HARTFORD CT 06033 USA 
VANCOUVER BC V7XiBi CANADA 
SAGINAW MI 48605 USA 
ALBUQUERQUE NM 87185 USA 
ENGLEWOOD CO 80140 USA 
RIVERSIDE CA 92507 USA 
ROSEBURG OR 97478 USA 
ST LOUIS KO 63166 USA 
LOUISVILLE GH 44641 USA 
SEATTLE WA 98124 USA 
EUGENE OR 97402 USA 
LIVERMORE CA 94550 USA 


NAME~6 


NAHE 


JEWEL MARTIN D 
JOERGER STEVEN 6 
JOHNSON BOB 
JOHNSON GARY L 
JOHNSON PAMELA 
JOHNSON RAYMOND E 
JOHNSON RON H 
JOHNSTON CHARLES F 
JOHNSTON FRANK H 
JOHNSTONE SHIRLEY J 
JONES DANNY A 
JONES MORGAN 

JONES THOMAS 0 
JORGENSON DANIEL Mf 
KAM POLLY 

KANAGA MIKE 

KASUN ELLEN 

KELLY KENT 

KENDALL JOHN 
KENFIELD JOHN E 
KENNEDY DOUGLAS 
KENNEDY JACK 
KERNXE JUTTA C 


TITLE 


HGR COMPUTER SERVICES 


INFO SYSTEMS MGR 

SYSTEM ANALYST 

HP 5000 PREM SERV HGR 
DISTRICT SALES MGR 

DATA PROCESSING MANAGER 
DIRECTOR DATA PROCESS 


COMPANY 


NATL SCI DATA CENTER 
ARMAMENT SYSTEMS INC 
GOV'T OF N W TERRITORIES 
HEWLETT-PACKARD 

BOEING COMPUTER SERVICE 
HEWLETT-PACKARD GSD 
HEWLETT-PACKARD 

FERRIS BSSCHER LOHMA 
MACON TELEGRAPH PUB CO 


SOFTWARE RELIABILITY ENG HEWLETT-PACKARD 


COMPUTER PROGRAMMER 


EXEC V P 

PRODUCT SUPPORT MGR 
PROGRAMMER/ANALYST 
SYSTEM ANALYST 


SYSTEMS PROGRAMMER 
INFO SYS MANAGER 
VICE PRESIDENT 
MANAGER SYS & PROG 
PRODUCT MANAGER 


KESSEL JIM (CANCELED) INDIVIDUAL 


KILLCOMMONS PETER F 
KILHON JR LIN E 
KING GAIL 

KING NEIL R 

KING STEPHEN E 
KIRK TIM L 

KLEIN JAMES D 
KLEIN THOMAS € 
KLETT DONALD § 
KLEVER JOHN 
KNICHT JR WILLIAM J 
KOBUCHI KENT K 
KOLSTO ELLIOT L 
KOMAR JAMES V 
KORNEK KEN 

KRIGER WINSTON A 
KROESEN JACOBUS A 
KROPP MICHAEL £ 
KUEHNER WARREN 
KUKUDA, JR. JOHN 
KUAVNICK HYER 
LACY LEROY P 

LAIR STEVE 
LANCASTER HENRY C 
LANCE JOHN H 
LARSON ORLAND J 
LARSON TERRY 
LASLEY HICHAEL A 


GENERAL COST SUPV 
SENIOR ENGINEER 
PROJECT MANAGER 
PROGRAMMING SUPV 
PROGRAMMER /ANALYST 
DIRECTOR INFO SYSTEMS 
SYSTEMS PROGRAMMER 
HGR INFO SYSTEMS 
DIRECTOR UNIVERSITY LAB 
ANALYST/PROGRAMMER 
MANAGER INFORMATION 
PROJECT SUPERVISOR 
MANAGEMENT ENGINEER 


LAWRENCE LIVERMORE LABOR 
TYMDATA CORP 

EPSILON DATA HGNT 
HEWLETT~PACKARD 
HEWLETT-PACKARD 

BOEING COMPUTER SERVICE 
HEWLETT-PACKARD 

FUTURA INC 

SO MISSIONARY COLLEGE 
H-P SANTA ROSA DIV 
FINANCIAL DATA PLANNING 
A G BECKER 
HEWLETT-PACKARD 


NEW YORK TELEPHONE CO 
WESTERN ELECTRIC CO 
BOEING COMPUTER SERVICE 
SCOTT PAPER LTD 
USAF 

SACRED HEART GEN HOSP 
INFORMATION TERMINALS 
HOOVER-NSK BEARING 
SANGAMON STATE UNIVERSITY 
AURORA PUBLIC SCHOOLS 
MULTIVEST INC 

BECHTEL CORP 

ARGONNE NATIONAL LAB 


DIRECTOR DATA PROCESSING THE H W WILSON CO, 


MGR TECHNICAL SALES 
HANAGER 0 & A 
SYSTEMS PROGRAMMER 
S E DISTRICT HGR 
VICE PRESIDENT 


COMPUTER SCIENTIST 

S E DSITRICT HER 

VP ENG DEV & COMP SCI 
PROGRAMHER ANALYST 
TMAGE PRODUCT MANAGER 
PROJECT LEADER 

HIS MANAGER 


COMPUTER SERVICE DIVISION 
HOUSTON INSTRUMENT 

HAKRO INTL 

NORWCH-EATON PHARM 
HEWLETT-PACKARD 


ADDRESS 


1130 E MC DOWELL RD 
712-F N VALLEY ST 


5800 HARMONY ROAD 

P Q BOX 24346 

5303 STEVENS CRK BLVD 
5600 DIC PKWY 

339 E L6TH STREET 

P 0 BOX 4147 

19400A HOMESTEAD RD 

P 0 BOX 808 

44 0 JEFFERSON ST 

24 NE EXECTIVE PK 

5303 STEVENS CREEK BLVD 
5301 STEVENS CREEK BLVD 
P 0 BOX 24346 

B15 14 SW 

1714 S CONGRESS 


1400 FOUNTAIN GROVE PK 
2670 TIGERTAIL AVENUE 
55 WATER STREET 

5303 STEVENS CREEK BLVD 
PQ BOX 124 

1095 AVE OF THE AMERICAS 
2500 BROENING HWY 

P 0 BOX 24346 

PQ BOX 760 

LOS ANGELES AIR FORCE STA 
P @ BOX 1090S 

323 SOQUEL WAY 

5400 S STATE RD 
SHEPHERD ROAD 

1085 PEORIA STREET 

6452 N FEDERAL HWY 

P 0 BOX 3965 

9700 SOUTH CASS AVENUE 
950 UNIVERSITY AVENUE 
19310 PRUNERIDGE AVE 
8500 CAMERON ROAD 
CHURCHILL LAAN if 

13-47 EATON AVENUE 

5600 DIC PKWY 


BUSINESS COMPUTER CONCEPTS RD #1 BOX 131-B 
MONTREAL CHILDRENS HOSPITA 2360 TUPPER 


LAWRENCE LIVERMORE LAB 
HEWLETT-PACKARD 
ENVIRONMENTAL ELEMENTS 
THE TORO COMPANY 
HEWLETT-PACKARD 

LYNES UNITED SERVICES 
HINDERLITER 


P 0 BOX 808 HC L-389 
19310 PRUNERIDGE RD 
5700 KOPPERS ST 

S825 JASMINE STREET 
5303 STEVENS CREEK BLVD 
309 GND AVE SW 

1240 N HARVARD 


ATTENDEE BY NAME 


CITY STATE ZIP COUNTRY 


PHOENIX AZ 85006 USA 
ANAHEIM CA 92804 USA 
YELLOWKNIFE NW XOE4HO CANADA 
FORT COLLINS CO 80524 USA 
SEATTLE WA 98124 USA 
SANTA CLARA CA USA 
ENGLEWOOD CO 80110 USA 
HOLLAND HI 49423 USA 
MACON GA 31288 USA 
CUPERTINO CA 95014 USA 
LIVERHORE CA 94550 USA 
BROWNSVILLE TX 78520 USA 
BURLINGTON HA 014803 USA 
SANATA CLARA CA 95050 USA 
SANTA CLARA CA 95050 USA 
SEATTLE WA 98124 USA 
LOVELAND CO 80537 USA 
AUSTIN TX 78704 USA 
COLLEGEDALE N 373iS USA 
SANTA ROSA CA 95404 USA 
MIAMI FL 33433) USA 
NEW YORK NY 10041 USA 
SANTA CLARA CA USA 
CHAGRIN FALLS 9H USA 
NEW YORK NY 10036 USA 
BALTIMORE MD 21224 USA 
SEATTLE WA 98124 USA 
NEW WESTHINST BC CANADA 
EL SEGUNDO ‘CA USA 
EUGENE OR 97404 USA 
SUNNYVALE CA 94086 USA 
ANN ARBOR MI 48106 USA 
SPRINGFIELD IL 62708 USA 
AURORA CO 80011 USA 


FT LAUDERDALE FL 33308 USA 
SAN FRANCISCO CA 94119 USA 


ARGONNE TL 60439 USA 
BRONX NY 10452 USA 
CUPERTINO CA 95044 USA 
AUSTIN TX 78753 USA 
3525 GVUTRECH NETHER 
NORWICH NY 13815 USA 
ENSLEWODD CO B8iii USA 
BURGETTSTOWN PA {5021 USA 
MONTREAL QU HSHiP3 CANADA 
LIVERMORE CA 74550 USA 
CUPERTINO CA 95014 USA 
BALTIMORE HD 21227 USA 
RIVERSIDE CA 92504 USA 
SANTA CLARA CA 95050 USA 
CALLARY AL TéPOCS CANADA 
TULSA OK 7441S USA 


NANE-7 


NAHE 


LAVIGLA ANTHONY 
LAW JACK 

LEE HAROLD 

LEE LANCE 


TITLE 


SYSTEMS MANAGER 
DATABASE ADMINSTRATOR 


SENIOR PROGRAMMER 


LEIGHT BETSY(CANCELED)DIRECTOR 


LEMLEY JOHN 

LESSEY KEN W 

LEVIN GREGG B 
LEWIN ROBERT € 
LEWIS GERALD 

LEWIS KERMON 
LIENARD JAMES B 
LIGHTHEART TED 4 
LINDSTROM EDWARD R 
LOCHNER CHRIS 
LOCKHEED ALLAN H 
LONG LYNDA J 

LOWRY GLEN H 

LUFT MARKUS F 
LUISI WILLIAM F 
LUITHLE WILLIARD H 
LULICH LEO J 

LUMB ARTHUR C 
LUNDBERG ERIK 

LYNN DEAN E 

MACHIN JOHN 
MAGDALENO JESUS 
MAGRUS ANN H 
MAHONEY LARRY 
MATER EDWARD F 
HALACHOWSKT ERNEST S 
fALUS JOSEPH T 
MANEWAL SANDRA S 
HANIES RALPH G 
MARCHESE BUZZ 


ASSOCIATE 

DESIGN ENGINEER 

THIRD PARTY PGH HGR 
VICE PRESIDENT 

V P DATA PROCESSING 
PROGRAMMER 
ANALYST/PROGRAHMER 
DIRECTOR-AGRI DATA CT 
SYSTEM MANAGER 


D P MANAGER 

INFO SYS MANAGER 
SYSTEMS & PROG SUPRYV 
SOFTWARE ANALYST 
COMPUTER OPS SUPV 
PROGRAMMER 
CONSULTANT 
SCIENTIFIC PROGRAMMER 
COMPUTER SCIENTIST 
MANAGING PARTNER 

ETE DE PROYECTOS 
SUPV COMPUTER OPER 


SUPERVISOR SEATTLE COMP 


INFO SYSTEMS EXECUTIVE 
CONTROLLER 


COMPANY 


NY TELEPHONE CO 
HEWLETT-PACKARD SDD 


ADDRESS 


375 PEARL ST 
16399 W BERNARDO DR 


FAIRFAX CNTY PUBLIC SCHOOL DATA SERVICES DIVISION 


GEGRGE WIMPEY CANADA 
LEIGHT AND ASSOCIATES 
HEWLETT-PACKARD 
DATACON 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
APPLIED ANALYSIS INC 
ROBERT JAMES CO 

NATL SCI DATA CENTER 


THE WILLAMETTE VALLEY CO 


UNIVERITY OF KENTUCKY 
FORD BOX i599B 

EXXON MINERAL CO USA 
EST 
HEWLETT-PACKARD 


DOMTAR CONSTRUCTION MTRLS 


UNION CAMP CORP 
KAISER FOUNDATION 
NORTHERN SPECIALTY 
PROCTER & GAMBLE CO 
CASS UNIV OF WASH 


LAWRENCE LIVERMORE LABOR 


INTERCOMP SERVICES 
INFORMATICA DESC, SC 
MULTNOMAH COUNTY ESD 
R W BECK & ASSOCIATES 
IL LAW ENFORCEMENT CO 
GRANVILLE-PHILLIPS CO 


SENIOR PROGRAMMER ANALYS MORGAN GUARANTY TRUST 
LIBERTY COMMUNICATIONS INC 2225 COBURG ROAD 


SYSTEMS MANAGER 
CUSTOMER RELATIONS 
SYSTEM MANAGER 


MARQUEZ MATEO(CANCEL) FIELD ENGINEER 


MPRSICEK RG 

AARTIN STEVE T 
MASSLINGER BOB 
MATHIAS TIMOTHY E 
MATT RICHARD G 

HAUS JOHN A 

MAY NORMAN F 

MAYHEW JOHN 

MC AFEE WILLIAM K 
MC CLAIN MALCOLM E 
MC CLURE HERSCHEL D 
MC CORMICK DOUGLAS B 
MC CRACKEN ED 

MC CREA ROBERT B 

MC GEOY JOHN G 

HC GRATH JOSEPH 


SYSTEMS ANALYST 
SYSTEM ANALYST 


HARDWARE PLANNER 
SYSTEMS ANALYST 
SR SYSTEMS ANALYST 


PRESIDENT 


MANAGER DATA PROCESSING 


MER SYSTEMS DEPT 
MER INFORMATION SYS 
GEN HER GS D 


CHIEF FINANCIAL OFFICER 


MER DATA SERVICES 


HEWLETT-PACKARD GSD 


80 NORTH QUEEN ST 
14200 SHOLES COURT 
BiS 14 SW 

SO WEST STREET 
$303 STEVENS CREEK 
5303 STEVENS CREEK 


645 SOUTH FLOWER STREET 


1130 E HC DOWELL RD 
&60 HC KINLGY ST 

5107 AG SCI CTR N 
SOUTHFIELD AT ROTUNDA 
604 JEFFERSON 

765 CALIFORNIA STREET 
P O BOX 45 

2004 UNIVERSITY ST 
4600 VALLEY RD 

2005 FRANKLIN 

6635 N BALTIMORE 
7162 READING RD 

£107 NE 45TH ROOK 530 
P 0 BOX 808 

459 COLLINS STREET 
THIERS 248 ANZUREZ 
220 SE i02 

200 TOWER BUILDING 
420 5 RIVERSIDE PLAZA 
5675 ARAPAHOE 

37 WALL STREET 


$303 STEVENS CREEK BLVD 


COMPUTER COMPOSITION SALES 2640 PINE ST 


HEWLETT-PACKARD MEXICO 


BOEING COMPUTER SERVICE 


SANDIA LABORATORIES 


BOEING COMPUTER SERVICE 


ANDERSON COLLEGE 
GENERAL HILLS INC 
H.H, GOLDEN CO 

IL LAW ENFORCEMENT CO 
AMERICAN SUBSRIP TV 
FUTURA INC 

NORTH IDAHO COLLEGE 
UNION CAMP CORP 
REPUBLIC GEOTHERMAL 
HEWLETT-PACKARD 

PORT OF VANCOUVER 
WESTINGHOUSE ELEC CORP 
TYADATA CORP 


AVENIDA PERIFERICO SUR 6504 TEPEPAN 


PO BOX 24346 
DIVISION 2627 
P Q BOX 24346 


9200 WAYZATA BLVD 

i23 CAMINO DE LA REINA 
120 S RIVERSIDE PLAZA 
8383 WILSHIRE BLVD 
1744 S CONGRESS 

4000 W GARDEN AVENUE 


{1823 E SLAUSON #1 
5303 STEVENS CREEK 
1500 STEWART ST 

P 0 BOX 8839 

44 W JEFFERSON ST 


ATTENDEE BY NAHE 


CITY STATE ZIP COUNTRY 


NEW YORK NY 10038 USA 
SAN DIEGO CA 92127 USA 
SPRINGFIELD VA 22i5i USA 
TORONTO ON M8Z2C9 CANADA 
LOS ALTOSHILL CA 94022 USA 
LOVELAND CO 80537 USA 
ST HELENS OR 97051 USA 
SANTA CLARA CA 95050 USA 
SANTA CLARA CA 95050 USA 
LOS ANGELES CA 90017 USA 
BIRMINGHAM = AL USA 
PHOENIX AZ 85006 USA 
EUGENE OR 97402 USA 
LEXINGTON KY 40506 USA 
DEARBORN MI 48121 USA 
HOUSTON TX 77604 USA 
SAN FRANCISCO CA 94108 USA 
BOISE ID 83707 USA 
MONTREAL QU HSAZAS CANADA 
WAYNE NJ 07470 USA 
DENVER CO 80205 USA 
PORTLAND OR 97203 USA 
CINCINNATI GH 45208 USA 
SEATTLE WA 98105 USA 
LIVERMORE CA 94550 USA 
MELBOURNE VI 3000  AUSTRA 
HEXICO DF MEXICO 
PORTLAND OR 97216 USA 
SEATTLE WA 78401 USA 
CHICAGO IL 60606 USA 
BOULDER CO 80383 USA 
NEW YORK NY 40015 USA 
EUGENE OR 97401 USA 
SANTA CLARA CA 95050 USA 
ST LOUIS HO 63483 USA 
X0 22 MEXICO 
SEATTLE WA 98124 USA 
ALBUQUERQUE NM 87185 USA 
SEATTLE WA 98124 USA 
ANDERSON IN 46041 USA 
MINNEAPOLIS #N 55426 USA 
SAN DIEGO CA 92108 USA 
CHICAGO IL 60606 USA 
BEVERLY HILLS CA #0211 USA 
AUSTIN TX 78704 USA 
COEUR D’ ALEN ID 83814 USA 
FRANKLIN VA 23851 USA 
SANTA FE SPRI CA 90670 USA 
SANTA CLARA CA 95050 USA 


VANCOUVER 
PITTSBURGH PA iS221 
BROWNSVILLE 1X 78520 


BC VSL4XS CANADA 


ISA 
USA 


NAME-8 


NAHE 


HC INNIS, JR. A MARVI 


RC LEMORE JIM 
NC LEOD PAT 
HC HURRAY JACK 


HC SHANE MICHAEL G6 


MECHAM DOUGLAS J 
MEDD RANDY 

MEINZ MICHAEL J 
MELVIN PETER § 
MENOLD BEN 
MERSHON ROBERT C 
METZNER BERNIE 
MEYER DIANNE HM 
MEYER JAMES J 
MEYERS BARRY 
MEYERS LAWRENCE 
HILLARD MICHAEL J 
MILLER DANIEL J 
MILLER LEROY ¥ 
MILLER STEPHEN L 
MILLER WILLIAM J 
MINOR TERRY 

HOCK MADISON 0 
HOIRAG DAVID E 
MONAHAN WILLIAM 
MOODY JERRY R 
HOORE GEORGE E 
MOORE ROBERT E 
MORAIN GLEN 
MORRISON JAMES C 
MOWER HONTE J 
MULLER MEREDITH A 
RULVIHILL GARY 
HURPHY DONALD C 
MURPHY JR ROBERT 
NAGEL PATRICK H 
NEAL RANDOLPH H 
NEIBERGS GEORGE J 
NELSON MARLYS 
NEMETH LOUIS E 
NEUMYER RICHARD D 
NEWELL RUSSELL L 
NEWMAN ALAN T 
NICHOLS MARTIN D 
NOLAN VINCENT 
NONAHAKER LAURA S 
NORRIS BOB 

NORTH CARL H 

GCHT YOSHIAKI 


TITLE 


SYSTEMS MANAGER 
PROGRAMMER 
DP MANAGER 


SYSTEMS COORDINATOR 
HP3000 SYSTEMS MGR 
SUPERVISOR , TECH SERVS 
DIRECTOR OF MARKETING 
SE DISTRICT HGR 
PROJECT MANAGER 
OPERATIONS MGR 
OPERATIONS COORDINATOR 
COMPUTER OPERATIONS 
NATIGNAL SALES HGR 
DIRECTOR OF MARKETING 
PROGRAMMING SUPERVISOR 
SYSTEMS ANALYST 

D P RANAGER 

COMP PROD SUPVR IT 
HGR CORP SYS PLANNING 
SYSTEMS MGR 

HGR INFO SYS BAG DIV 
PROGRAMMING MANAGER 
DEVELOPHENT KER 
SYSTEMS SUP 
OPERATIONS MANAGER 
PRESIDENT 

COMPUTER SERVICES DIV 
MANAGER D P 

SYSTEM MANAGER 
PROGRAMMER/ANALYST 


SYSTEH MANAGER 

DIRECTOR ADMINISTRATION 
SYSTEHS PROGRAMMER 
PRESIDENT 

IS MANAGER 


DIRECTOR ENG COMP CTR 
SENIOR ENGINEER 
SYSTEMS ANALYST 

INFO SERVICES MGR 
TECHNICAL ANALYST 


PROGRAMMER/ANALYST 
PROGRAMMER ANALYST 
DIRECTOR COMPUTER CTR 
EDP MANAGER 


OLSEN MARY ANN(CANCEL PROGRAMMER 


OLSON BRIAN 
GMI G KEVIN 


SENIGR ANALYST 
MANAGER 


COMPANY 


MINI/MICRO SYSTEMS INC 


DEPT OF ENERGY 
SCOTT PAPER LTD 


DOMINION CONSTRUCTION 


HUGHES AIRCRAFT CO 


BOETTCHER & CO 


GENERAL MILLS, INC 


CHC ASSOCIATES 
HEWLETT-PACKARD 
IVT FINANCIAL 


PILKINGTON GLASS LTD 
PROCTER & GAMBLE CO 


COPCO 


UNITED COMPUTING SYS 
SYSTEMS RESEARCH INC 
OKANAGAN HELICOPTERS 
ENVIRONMENTAL ELEMENTS 
NORTHERN SPECIALTY SALES 
TL DEPT OF CORRECTION 
THE BOVAIRD SUPPLY CO 
DONNELLY MIRRORS INC 


UNION CAMP CORP 


LONGS DRUG STORES, INC 


34 
DEPT OF ARMY 


INTERACTIVE APPL INC 
EDUCATIONAL COMPUTER SYS 


HEWLETT-PACKARD 


SUN HYDRAULICS CORP 
~ PROVO SCHOOL DISTRICT 


BOEING 


R SHRIVER ASSOCIATES 
BOEING COMPUTER SERVICES 
TEXAS MUNICIPAL POWER 


UNION OIL COMPANY 


AUTOMATED BUSINESS SV 


ESB-EXIDE 


UNIVERSITY OF WISCONSIN 


PHILA WATER DEPT 


WESTERN ELECTRIC CO 


VOFM-DEARBORN 
TOWER MANAGEMENT 
UNION CAMP CORP 


UNITED HC GILL CORP 


UNION OIL COMPANY 


SAN JOSE MERCURY-NEWS 
THOMAS NELSON COM COL 
MATSUSHITA ELEC INDUST CO 
MITCHELL BROS TRUCK 
APPLIED ANALYSIS INC 


WELLS FARGO BANK 


ADDRESS 


S315 N SHARTEL AVE 


1330 BROADWAY 
PO BOX 740 


5100 3 BENTALL CENTRE 
ASSOC DIRECTOR COMPUTING ASSOC AMERICAN HED COLLEGE ONE DUPONT CIRCLE SUITE 200 WASHINGTON 
PQ BOX 3310 601-4219 


828 17TH STREET 
PO BOX 1143 
3 MARGARET ST 


5303 STEVENS CREEK 
PQ BOX 25) 


685 WARDEN AVE 


6105 CENTER HILL RD 
4905 LIMA STREET 


{901 AVE OF STARS 


2400 SCIENCE PARKWAY 
4391 AGAR DRIVE 
5700 KOPPERS ST 
6635 N BALTIMORE 


200 W WASHINGTON 
823 S DETROIT 

49 W SRD ST 

P QO BOX 1825 


£41 NORTH CIVIC DR 


SM CTR 223-5N 


BLDG 12500 ATTN DXRMC-C-C 
505 HAMILTON AVE #103 


1513 KEMPER RD 


19340 PRUNERIDGE AVE 


{817 57TH STREET 


280 WEST 800 NORTH 

PQ BOX 3707 MS 3N-03 
1530 CHESTNUT SUITE 744 
PQ BOX 3707 4/S36-04 
600 ARLINGTON DOWNS 
{35TH ST & NEW AVE 


1649 W BROAD ST 
{01 GIBRALTOR RD 


{270 HSB 
2500 BROENING HWY 
4901 EVERGREEN 


{779 TRIBUTE ROAD #H 


4600 VALLEY RD 
2400 FAIRWOOD AVE 


461 BOYLSTON RM 4327 
750 RIDDER PARK DR 


PO BOX 9407 


#2 MATSUSHITA MACH 
5B4i N COLUMBIA BLVD 
615 SOUTH FLOWER STREET 


420 MONTGOMERY ST 


ATTENDEE BY NAKE 


CITY STATE ZIP COUNTRY 


OKLAHOMA CITY OK 73118 USA 


OAKLAND CA USA 
NEW WESTMINST BC CANADA 
VANCOUVER BC V7XiBi CANADA 
DC 20036 USA 
FULLERTON CA 92634 USA 
DENVER CO 80202 USA 
MINNEAPOLIS HN 55440 USA 
BOSTON MA 02021 USA 


SANTA CLARA 


CA 95050 USA 


CHIPPEWA FALL WI 54729 USA 


TORONTO 


CINCINNATI 


DENVER 


LOS ANGELES 


OKENOS 


VANCOUVER 
BALTIMORE 


PORTLAND 


SPRINGFIELD 


TULSA 
HOLLAND 
SAVANNAH 


WALNUT CREEK 


ST PAUL 
FORT LEE 


PALO ALTO 
CINCINNATI 
CUPERTINO 


SARASOTA 
PROVO 
SEATTLE 


PHILADELPHIA 


SEATTLE 


ARLINGTON 


LEMONT 
RICHMOND 
HORSHAM 


RIVER FALLS 
PHILADELPHIA 
BALTIMORE 


DEARBORN 


SACRAMENTO 


WAYNE 
COLUMBUS 


LOS ANGELES 


ON MiL3X7 CANADA 
OH 45220 USA 
CD 80239 USA 
CA 90067 USA 
MI 48864 USA 
BC V7BiAS CANADA 
MD 21227 USA 
OR 97283 USA 
IL USA 
OK 74102 USA 
MI 47423 USA 
GA 31402 USA 
CA 94596 USA 
HN SS00i USA 
VA 23801 USA 
CA 94301 USA 
GH 45246 USA 
CA 95014 USA 
FL 33580 USA 
UT 84601 USA 
WA 98124 USA 
PA 19102 USA 
WA 98124 USA 
TX 760ii USA 
IL 60439 USA 
VA USA 
PA 197044 USA 
WI 54622 USA 
PA 19107 USA 
MD 2f2e4 USA 
MI 48128 USA 
CA 95815 USA 
NJ 07470 USA 
QH 43207 USA 
CA 90017 USA 


SAN JOSE CA 95190 USA 
HAHP TON VA 23670 USA 
MORIGUCHI-SHI 05 JAPAN 
PORTLAND OR 972417 USA 


LOS ANGELES CA 90017 USA 
SAN FRANCISCO CA 944144 USA 


NAHE-9 


NAHE 


ONEY JAMES B 
ONIZUKA SANDRA Fi 
ONYX ROBERT P 
OSBORNE LEE K 
OSCARSSON HANS 0 
QUELLETTE MARC E 
PACHALY FRED A 
PAGE JON 

PAPPAS STEVE 
PARELLA MIKE 
PARKER KENNETH 
PASHAK JAMES W 
PENNALA ERIC # 
PERKINS ALAN L 
PETERS HAROLD J 
PETERSON DON 
PETERSON DONALD C 
PETERSON MERRILL A 
PETTERCHAK JOHN J 
PHILLIPS TERRY 
PICK V MICHAEL 
PIEKARSKI DAVID Hi 
PIERCE ANTHONY 
PIPER MICHAEL 
PLEASANTS JOYCE B 
POLAXCWSKT KEN 
POLHEMUS JAN R 
POLO FRANK 


TITLE 


DATA PROCESSING MANAGER 


SYSTEM MANAGER 

D P GPER MANAGER 
DEVELOPMENT ENGINEER 
MANAGER 

SOFTEWARE SPECIALIST 
PROGRAMMER 

PROJECT MANAGER 


PRESIDENT 

DIRECTOR £ DP 
COMPUTER SPECIALIST 
MANAGER PROG & OPS 
SYSTEMS MGR/PGHR 
PRESIDENT 

SYSTEMS PROGRAMMER 
MGR SYSTEMS ANALYST 
STAFF ENGINEER 

INFO SYST EXECUTIVE 
DEVELCPHENT MANAGER 
RESEARCH COMPUTER MGR 
SUPVR COMPUTER UTILIZ 
SR SYSTEMS ANALYST 


COMPANY 


RCH 

CANCER CENTER OF HI 
FOSECO INC 
HEWLETT-PACKARD 

AB TRAV OCH GALOPP 
INCO LIMITED 
PURITAN INSURANCE CO 
HEWLETT-PACKARD 
AMERICAN SUBSCRIP TV 
DECISION STRATEGY 
PARISIAN INC 

DEPT OF ENERGY 
SPRECKELS SUGAR DIV 
WHITE HOUSE COMM 


ADDRESS 


ONE MARKET PLAZA 3718 
4450 SOUTH KING ST 
20200 SHELDON ROAD 
1046 S WINCHESTER #9 
BOX 1733 

i FIRST CANADIAN PL 
{SiS SUMMER ST 

5303 STEVEN CREEK 
8383 WILSHIRE BLYD 
708 THIRD AVENUE 
{401 26TH STREET N 
{333 BROADAY 

50 CALIFORNIA ST 
THE WHITE HOUSE 


EDUCATIONAL SOFTWARE PRODU 9 GEORGETOWN CIRCLE 


US CIVIL SERV COHM 
COLO DEPT GF HIGHWAYS 
JEFFERSON CHEMICAL 
IL DEPT OF CORRECTION 
SACRED HEART GEN HOSP 


GRUMMAN AERO SPACE CORP 


CHRYSLER CORPORATION 
BOEING AEROSPACE 


DIRECTOR DATA PROCESSING AURORA PUBLIC SCHOOLS 
GRP HGR SOFTWARE SUPPORT VYDEC INC 


HGR BUSINESS SYSTEMS 
SYSTEMS SPECIALIST 


PORTERFIELD STEPHEN T HP30G0 SYSTEM MANAGER 


POWERS DENNIS D 
PREDMORE LIONEL A 
PRELLE JEAN 

PRICE RICHARD J 
PRICE ROGER 


PRILL BOB (CANCELED) 


PRITCHARD G BRIAN 
PROCHNOW NEAL 


DIRECTOR INFO SERVICE 


AUSTIN INFORMATION SYS 
NORTHROP CORP 

BECHTEL CORPORATION 
WH C BROWN PUB COKPANY 


INFORMATION SYSTEMS SUPV CITY OF TERFE 
ECOLE SUPERTEURE DE COMMER 23 ROUTE DE DARDILLY 


PROFESSOR 

MGR TECH SUPPORT 
SYSTEMS ANALYST 
OPERATIONS MANAGER 
SR PROGRAMMER 


PUTEGNAT MICHAEL (CANC PRESIDENT 


RADOFF IRVING 
RASHUSSEN BENT 
RAUH JOSEPH E 
RAWSON TOK 

RECO F ALFREDO 


SUPVR SYS/PROG 
VICE PRESIDENT 
TECHNICAL SHOWHAN 
SYSTEMS PROGRAHHER 
PROFESSOR 


REITHNER JR ROBERT MH MANAGER 


RICE ROBERT J 
RICKARD € ALLEN 
RIEGER DENNIS E 
RITCHIE CLIFFORD E 
ROBERTS RICHARD A 
ROBERTSON DENNIS L 
ROBINSON JOEL # 
RODGER JGHN D 
RODRIGUEZ DAN R 


SYSTEMS ANALYST 


NER SYSTEMS DEVELOPMENT 


PRODUCT HANAGER - HPE 
D P RANAGER 


NATIONWIDE FINANCE 
THE BOVAIRD SUPPLY CO 
HEWLETT-PACKARD SDD 
CANADA BLDG HATERTIALS 


UNIVERSITY OF WISCONSIN 


CONTROL SYSTEMS 

VSI CORPORATION 

R SHRIVER ASSOCIATES 
ISSCO 

CASS UNIV OF WASH 
UNIV F HARROQUIN 
N.E.R.A. 

ADAMS COUNTY SCHOOLS 
NATIONWIDE FINANCE 
HEWLETT-PACKARD 
BENEFIT TECHNOLOSY 


MGR SYSTEM & PROGRAMMING B&S FINANCIAL SERVICES 


NER DIST PROC TECH SP 
MGR INFORMATION SYS 


PROJECT LOR SUPPLY 


WEYERHAEUSER CO 
GECRGE WIMPEY CANADA 
NORTHERN TELECON 
STANDARD OIL CO 


4685 LOG CABIN DR 
4204 E ARKANSAS 
P 0 BOX 847 

200 N WASHINGTON 
P 0 10905 

A 08-35 


PO BOX 1949 CINS:4462725 


P 0 BOX 3999 

{9601 NORDHOFFF 

4085 PEORIA STREET 

9 VREELAND RD 

800 SW L6TH STREET 
2501 WEST £26 STREET 
P 0 BOX 3965 

2460 KERPER BLVD 

Si & FIFTH BOX $062 


706 OFFICE PARKWAY 
823 § DETROIT 

16399 WU BERNARDO DR 
SS INDUSTRIAL ST 


44 W JEFFERSON ST 
8463 HIGUERA ST 
129 LITTLETON ROAD 


4186 SORRENTO VALLEY BLVD 


1107 NE 45TH ROON S36 
6A AVE O-28 ZONA 10 
BO BROAD STREET 

602 E 64TH AVE 

700 OFFICE PARKWAY 


S303 STEVENS CREEK BLVD 


960 LAFAYETTE STREET 
N COUNTY ROAD 25A 


{0TH & A STREETS RMB-i 


80 NORTH QUEEN ST 
8200 DIXIE RD 
{090 GUILDHALL BLDG 


ATTENDEE BY NAHE 


CITY STATE ZIP COUNTRY 


SAN FRANCISCO CA 94165 USA 
HOXOLULU RA 96814 USA 
BROOKPARK OH 44142 USA 
SAN JOSE CA 75128 US 
STOCKHOLM SW 11187 SWEDEN 
TORONTO ON MSX1C4 CANADA 
STAMFORD CT 06965 USA 
SANTA CLARA (CA 95050 USA 
BEVERLY HILLS CA 90211 USA 
NEW YORK NY 19017 USA 
BIRMINGHAM == AL 35254 USA 
OAKLAND CA 94461 USA 
SAN FRANCISCO CA 94141 USA 
WASHINGTON DC 22070 USA 
1QWA CITY TA S2240 USA 
MACON GA 3i2i0 USA 
DENVER CO s022e USA 
PORT NECHES 1X 77651 USA 
SPRINGFIELD IL USA 
EUSENE OR 97401 USA 
BETHPAGE NY 44714 USA 
DETROIT KI 48288 USA 
SEATTLE WA 98124 USA 
NO RIDGE CA USA 
AURORA CO 80012 USA 
FLORHAM PARK NY USA 
RENTON WA 78055 USA 
HAWTHORNE CA 96256 USA 
SAN FRANCISCO CA 94419 USA 
DUBUGUE TA 52001 USA 
TEMPE AZ 85281 USA 
ECULLY FRANCE 
CREVE COEUR MO 63141 USA 
TULSA OX 74182 USA 
SAN DIEGO CA 92127 USA 
TORONTO ON H4GIN9 CANADA 
RIVER FALLS WI 54022 USA 
BROUNSVILLE 1X 78520 USA 
CULVER CITY CA 98230 USA 
PARSIPPANY NJ 67054 USA 
SAN DIEGO ©: CA 92i2t USA 
SEATTLE WA 98105 USA 
GUATERALA GUATEN 
NEW YORK NY 18004 USA 
DENVER CO 88229 USA 
CREVE COEUR MO G3i4i USA 
SANTA CLARA CA 95650 USA 
SANTA CLARA CA 95859 USA 
PIGUA OW 45356 USA 
TACOMA VA 98401 USA 
TORGNTO ON H8Z2C9 CANADA 
BRAMPTON ON LOV2HS CANADA 
CLEVELAND OH 44115 USA 


NAME-10 


NAME 


ROGERS THORAS D 
ROSENBERG IVAN H 
ROSS PATRICK D 
ROUSSEAU ALLEN F 
ROWE THOHAS C 
RUSSELL BRIAN G 
RUSSELL JIM 
RUSSELL KENT A 


RUTHERFORD CLYDE R 


RYAN GEOFFREY 
SALINS GARY E 
SARBAUGH JAY C 
SCHICK JOHN A 


TITLE COMPANY 


ASSISTANT DIRECTOR NORFOLK STATE COLLEGE 


GENERAL PARTNER SYSTEMS DESIGN ASSOC 
SR MEMBER TECHNICAL STAF BSL INC 

VP PRODUCT DEV KEYDATA CORP 

V P SYSTEMS NATIONWIDE FINANCE 
PROGRAMMER /ANALYST WEST FRASER MILLS 
PRESIDENT COMPUTER SERVICES CORP 
PRESIDENT NATIONAL COMPUTER CORP 


OUPV HSS COMPUTING BOEING COMMERCIAL AIR 
CONTROL SYSTEMS 

DATA PROCESSING MANAGER DARE PAFCO, INC 

VICE PRESIDENT SMALL BUSINESS DATA PROC 


PROGRAMMER WAC BROWN PUB COMPANY 


SCHLOSSER JR ROBERT J COMPUTER SCIENTIST PEPCO 


SCHULER KURT J 


SCHWARTZ RICHARD T 


SCHWARTZ RICK A 
SCHWARZ RAYROND T 
SCOTT GEORGE B 
SCROGGS ROSS E 
SEIFRIED W BRIAN 
SELLERS HARRY P 
SEVEBORG KARL E 
SEWELL DAVID 
SHAULIS MICHAEL 


SHEFFIELD REBECCA L 


SHELLEY NANCY 
SHOUP BRYAN 


SHROADS, JR JANES C 


SHUMATE D CRAIG 
SILVER GAYE L 


SIMONSEN J LAWRENCE 


SIMS RICH 

SINHA DEEPAK 
SISOIS HIKES N 
SJOGREN DAVID R 
SLATER TED 
SLGAN DAVID L 
SHART JOHN E 
SHELSER LINDA C 
SHITH BARRY 
SMITH HOWARD J 
SHITH JR HARRY R 
SHITH RAYROND E 
SHITH ROGER 
SMITH TERRY B 
SNEED JAKES E 


SNELLINGS FRANK W 
SNESRUD MARGARET J 


SRESRUD WALLY Hf 
SOCIE LARRY J 
SOHALE RONALD C 


DIR / COMP SERVICES UNIVERSITY OF DALLAS 


PRINCIPAL 

DIST CE HANAGER HEWLETT-PACKARD 

HINI-OPERATIONS MGR HEWLETT-PACKARD 

MANAGER REICHHOLA CHEN 
ALTERSABILITY 


SUPERVISOR SYSTEMS APPL BONAR & BEMIS LTD 
ADH DP MANAGER VA WESTERN CON COL 
CIVIL ENGINEER AB BOFGRS 
DIRECTOR OF DATA PROCESS SII SERVCO 


FAIRFAX CNTY PUBLIC SCHOOL DATA SERVICES DIVISION 


STUDENT ANDERSON COLLEGE 
SYSTENS PROGRAMMER SCOTT PAPER LTD 
DATA PROCESSING HER SII DYNA-DRILL 


DIRECTOR COMP OPER 
MANAGER CS D 


NPD REASEARCH, INC 
WARREN & VAN PRAAG 


SYSTERS ANALYST TRW COLORADO ELECT 

CORPUTER SYSTEMS ENGR VALTEK INC 

EXEC V P ATI 

PROGRAMMER MC MASTER UNIVERSITY 

DIRECTOR INFO SYSTEMS UNIV GF SANTA CLARA 

SYSTEM SPECIALIST GENERAL MILLS 

SALES REP HEWLETT-PACKARD 

CONSULTANT COLLIER-JACKSON ASSOC 

VICE PRESIDENT SILTON DATA INC 

ASST GENERAL KGR STATE CONTROLLERS OFFICE 
PRUDENTIAL INSURANCE 

LAB MANAGER HEWLETT-PACKARD 


DIRECTOR, COMPUTER CTR HOWARD COMMUNITY COLLEGE 


BATA PROCESSING MANAGER POWERS REGULATOR 


DP HANAGER DONNELLY MIRRORS INC 
CHIEF OF DATA PROCESSING HILO BEAUTY SUPPLY CO 
CORPORATE HER D P RELIANCE ELECTRIC 
PROJECTS DEV HANAGER MEDIA GENERAL INC 
PROJECT DIRECTOR WN C BROUN PUB CORPANY 
PROGRAMMER Wi C BROWN PUB COMPANY 
PROGRANMER HDOVER-NSK BEARING 


MER COMPUTING SERVICES REGICNAL ECONOMIC EXPANSIO 601 SPADINA CRESCENT 


ADDRESS 


2404 CORPREW AVE 
PQ BOX 1144 
495 JAVA 

108 WATER ST 


700 OFFICE PARKWAY 


BOX 6000 


75 RANHATTAN DR #107 


5000 34TH ST 


P 0 BOX 3707 H/S SF-09 
44 W JEFFERSON ST 

14353 REED HARTMAN HY 
4208 AIRPORT ROAD 


2460 KERPER BLVD 
£906 PENNA AVE 


AMERICAN MANAGEMENT SYSTEM S6i PILGRIM DRIVE SUITE D 
6877 GOREWAY DRIVE 
1501 PAGE MILL RD 


2340 TAYLOR WAY 
534 ROSAL AVENUE 


2380 MC DOWELL ROAD 
S095 COLONIAL AVE 


BOX 506 
PO BOX 880 


P 0 BOX 768 


1771 DEERE AVENUE 
{5 VERBENA AVENUE 
{276 NORTH WARSON RD 
3450 N NEVADA AVE 
MOUNTAIN SPRINGS PRKWY 
5532 § HILLCREST DR 


4208 MAIN ST W 
BANNAN HALL 113 
PO BOX 1113 


{0674 SHELLBRIDGE WAY 
{805 N WESTSHORE BLVD 
2407 E JOTH STREET 


504 E MUSSER 


213 WASHINGTON ST 
$303 STEVENS CREEX 
LITTLE PATUXENT PKUY 


RR $1 
49 W ORD ST 
4670 ALLEN ROAD 


P 0 BOX 5065 STATION B 


301 & GRACE ST 
2460 KERPER BLVD 
2460 KERPER BLVD 
5400 S STATE RD 


ATTENDEE BY NANE 


CITY STATE ZIP COUNTRY 


NORFOLK VA 23504 USA 
SAN LUIS OBIS CA 93406 USA 
SUNNYVALE CA 74086 USA 
WATERTOUN HA 02172 USA 
CREVE COEUR AS 63144 USA 
QUESNEL BC V2I3JS CANADA 
BOULDER CO 80383 USA 
METAIRIE LA 70061 USA 
SEATTLE VA 98124 USA 
BROWNSVILLE TX 78520 USA 
CINCINNATI OH 45040 USA 
CINCINNATI GH 45226 USA 
DUBUQUE TA S2001 USA 
WASHINGTON DC 20068 USA 
IRVING TX 75861 USA 
SAN HATEO CA 94404 USA 
MISSISSAUGA ON LAVIMB CANADA 
PALO ALTO CA 943504 USA 
TACOKA WA 98401 USA 
GAKLAND CA 94618 USA 
BURLINGTON ON L7R4AL CANADA 
ROANOKE VA 24015 USA 
BOF ORS 569020 SWEDEN 
GARDENA CA 99247 USA 
SPRINGFIELD VA e2i5i USA 
ANDERSON IN 46041 USA 
NEW WESTMINST BC CANADA 
IRVINE CA 92713 USA 
FLORAL PARK NY £1984 USA 
ST LOUIS MO 63132 USA 
COLORADO SPRI CO 60907 USA 
SPRINGVILLE UT 84663 USA 
DENVER CO USA 
HAMILTON ON L8S4J9 CANADA 
SANTA CLARA CA 95053 USA 
MINNEAPOLIS HN SS440 USA 
RICHHOND BC VOX2¥7 CANADA 
TRHPA FL 33607 USA 
VERNON CA 90658 USA 
CARSON CITY NV 89791 USA 
NEWARK WJ 07404 USA 
SANTA CLARA CA 95050 USA 
COLUMBIA MD 21044 USA 
BEETON ON LOGLAS CANADA 
HOLLAND MI 49423 USA 
STOW OH 44224 USA 
GREENVILLE SC 29606 USA 
RICHKOND VA 23219 (USA 
DUBURUE TA S2001 USA 
DUBUQUE IA S200i USA 
ANN ARBOR HI 48106 USA 
SASKATOON = SA S7K3G8 CANADA 


NANE-1i 


NAME 


SOMERS PETER 

SPAHN CARL P 
SPALDING KENNETH & 
SPERLE GLENN ¥ 
SPIELER CHARLES W 
SPORKEN HEIN P 
SQUIRES JH 

ST PIERRE JEAN 
STAMBAUGH JAN R 
STARCK RICHARD E 
STARK JOHN A 

STEIN SALLYSUE 
STOCKDALE WALLACE L 
STOVER DAVID W 
STOVER RAY J 
STRANDHAGEN DEBRA A 
STUMP DALE K 
SULLIVAN DENNIS J 
SULLIVAN EARLENE 


SURR T 


SWEARER DALE F 
SYMONDS GORDON R 
SYNOLD PRISCILLA J 
TANKERSLEY JAMES J 
TANTZEN ROBERT G 
TARENS MICHAEL R 
TATHAN PAUL E 
TAYLOR DAVID W 
TAYLOR MIKE 

TAYLOR PAUL ¥ 
TEARE ROBERT F 
TEKLITS ROBERT § 
TENBROCT JCE R 
TETI FRANK A 
THEISSEN WILHELM J 
THOMASSON GARY 
THOMPSON JIM 


TITLE 


DIRECTOR ADSS 
DEVELOPMENT ENGINEER 
COMPUTER SPECIALIST 
DIRECTOR HIS 


SYSTEMS ENGR 

DP MANAGER EMD 
DIRECTOR BP 
PRESIDENT 

SYSTEMS ENGINEER 
PARTNER 

DP HANAGER 

DIR OF INFO SERVICES 


SYSTEM CONTROL 
DATA PROCESSING HER 
MGR D P OPERATIONS 
DATA COORDINATOR 


SYSTEMS ANALYST 

HEAD COMPUTER APPLIC 
MANAGER TECHNICAL SPT 
SR SYSTEMS ANALYST 
CHIEF PROGRAMMING 
REGIONAL HKTG ENGINEER 
SYSTEMS MANAGER 
SYSTEMS ANALYST 
PROGRAMER 

COMPUTER SPECIALIST 
ASST DIR BIBL SERV 
DATA MANAGEMENT SUPVR 
DP HANAGER 

SYSTEM ANALYST 
MANAGER BUSINESS SYST 
FAC INFO SYS MANAGER 


THOMPSON JR CHARLES H INFORMATION MGMT CHF 
THOMPSON RANDY (CANCEL ANALYST 


THOHSON RON 
THORMAN BEN 
THORNTON WILLIAM L 
TICHAUER MARIO F W 


TIER PAUL 


TIGELHAN ROBERT J 
TONNESEN LARRY D 
TOWNSEND RICHARD 
TRAPP ROBERT £ 
TRAPPE CLARENCE J 
TROWBRIDGE VERN H 
TRUE JOHN F 
TSUKISHIMA LLOYD # 


DATA PROCESSING MGR 
ASST DP MGR 
PROGRAMMER /ANALYST 
ENGINEER 

MARKETING MANAGER 
DATA PROCESSING HER 
SYSTEMS MANAGER 
PROGRAMMER/ANALYST 
TEST ENGINEER 
SYSTEMS PROGRAMHER 
MGR DATA PROCESSING 
DIR COMPUTING SERVICE 
PROGRAHMER/ANALYST 


COMPANY 


CAPE ISLAND HARINA 
US DEPT AGR-APHIS 
HEWLETT-PACKARD 

US DEPT OF AGR-APHIS 
SIMCO 

NOVA AUTONATION CONS 
HEWLETT-PACKARD 
SCOTT PAPER LTD 
MULTNOMAH COUNTY ESD 


ADDRESS 


OCEAN DRIVE 

6525 BELCREST RD #853 
S303 STEVENS CREEK 
6525 BELCREST RD #853 
21084 CABOT BLVD 

30 NEDEREIND 

4430 E ORANCETHORPE 
PO BOX 760 

22) SE ibe 


BUSINESS COMPUTER CONCEPTS RD #1 BOX 13i-B 


HEWLETT-PACKARD 
T.0.A.D. 

PORT OF GAXLAND 
TELEPHONE EMPLOYEES CO 
INFORMATION RESOURCES 
WILLIAM M MERCER INC 


STATE CONTROLLERS OFFICE 


NATIONWIDE FINANCE 
CITY OF KENNEWICK 


BOEING COMPUTER SERVICE 


ENVIRONMENTAL ELEMENTS 
ENVIRONMENTAL HEALTH 
T5600 

PROCTER & GAMBLE 


HEWLETT-PACKARD 
HMO SYSTEMS INC 


BOEING COMPUTER SERVICES 


ATI 

US DEPT AGRICULTURE 
THE CLAREMONT COLLEGES 
COLGRADO DEPT EDUC 
HEWLETT-PACKARD 
MORGAN GUARANTY TRUST 
HUGHES AIRCRAFT CO 
HEWLETT-PACKARD 


GOV'T OF NW TERRITORIES 


SPACE & HSL SYS DIV 
ATI 

THE BOVAIRD SUPPLY CO 
FLINT INDUSTRIES INC 
MASTERCRAFT IND 
PROMON ENGENHARIA S A 


DC DUMHER & ASSOCIATES 


BEACON JOURNAL PUBL 
GUARDSHAN LIFE INS 


UNITED PRESIDENTIAL LIFE 


HUGHES AIRCRAFT CO 
BECHTEL CORP 
TIDEWATER CONM COLL 
UNIV OF TENNESSEE 
WEST FRASER MILLS 


4203 i44TH SE 

{9855 GIESENDORFER RD 
66 JACK LONDON SQ 

639 S NEW HAMPSHIRE 
4905 LIMA 

409 GRISWOLD 

S04 E MUSSER 

700 OFFICE PARKWAY 
210 W 4TH 

PO BOX 24346 

3708 KOPPERS ST 
TUNNEYS PASTURE 

4486 SORRENTO VALLEY BLVD 
P 0 BOX S99 

658 STH TEST GROUP/AD 
19400 HOMESTEAD RD 
{235 RIVERSIDE 

P O BOX 24346 

3532 § HILLCREST DR #3 
6525 BELCREST RD #853 
HONNOLD LIBRARY 

evi E COLFAX 

S304 STEVENS CREEK 

23 WALL STREET 

P QO BOX 3340 607/B318 
PO BOX 46 


2805 MAPLE AVENUE 
3532 S HILLCREST DR #3 
823 S DETROIT 

P 0 BOX 490 

4981 IRONTON ST 

NOVE DE JULHO 4939 
49 LK LUCERNE CL SE 
44 E EXCHANGE ST 
4025 ASHWORTH ROAD 
217 SOUTHWAY BLYD E 
1904 W MALVERN AVE 
350 MISSION STREET 
RT 135 

615 HC CALLIE AVENUE 
P 0 BOX 6000 


ATTENDEE BY NAME 


CITY STATE ZIP COUNTRY 


CAPE RAY NJ 08204 USA 
HYATTSVILLE MD 20782 USA 
SANTA CLARA CA 95050 USA 
HYATTSVILLE MD 20782 USA 
HAYWARD CA 94545 USA 
NIEUNEGEIN NETHER 
FULLERTON CA 92631 USA 
CRABTREE Pq CANADA 
PORTLAND GR 97216 USA 


BURGETTSTOWN PA {S024 USA 


BELLEVUE WA 98004 USA 
COLFAX CA 95743 USA 
QAKLAND CA 94606 USA 
LOS ANGELES CA 90005 USA 
DENVER CO USA 
DETROIT HI 48226 USA 
CARSON CITY NV 89701 USA 
CREVE COEUR MQ 63141 USA 
KENNEWICK WA 99336 USA 
SEATTLE WA 98124 USA 
BALTIMORE HD 24227 USA 
OTTAWA GON KiAOL2 CANADA 
SAN DIEGO CA 92121 USA 
CINCINNATI Ot 45204 USA 


HOLLOMAN AFB NH 88330 USA 


CUPERTINO CA 95014 USA 
FT COLLINS CO 80S2i USA 
SEATTLE WA 98124 USA 


DENVER CO USA 
HYATTSVILLE MD 20782 USA 
DARTMOUTH AT CA 91711 USA 


DENVER Co 80203 USA 
SANTA CLARA CA 95050 USA 
NEW YORK NY 10045 USA 
FULLERTON CA 92634 USA 
BOISE ID 83707 USA 


YELLOWKNIFE NW XOESHO CANADA 
HANHATTAN BEA CA 90266 USA 


DENVER CO USA 
TULSA OK 74402 USA 
TULSA OK 74104 USA 
DENVER CO 80239 USA 
SAO PAULO SP 01407 BRAZIL 


CALGARY AL T2J3HB CANADA 
AKRON OH 44328 USA 
WEST DESMOINE IA $0265 USA 
KOKCKO IN 46901 USA 
FULLERTON CA 92634 USA 
SAN FRANCISCO CA 94165 USA 
PORTSMOUTH VA 23704 USA 
CHATTANOOGA TN 37482 USA 
QUESNEL BC V2J375 CANADA 


NAKE-12 


ATTENDEE BY RAME 


NAME TITLE COMPANY ADDRESS CITY STATE ZIP COUNTRY 
TURNER WILLIAM A PROF ASSOCIATE WILLIA M MERCER INC 409 GRISWOLD DETROIT MI 48226 USA 
TWYHAN DONALD R DIRECTOR INFO SYSTEMS © AMERICAN RED CROSS {00 E RACK DETROIT HI 48201 USA 
UTTER ROGER § COMPUTER APPLICATIONS | EXXON NUCLEAR CO 777-106 TH AVE NE BELLEVUE WA 98009 USA 
VALERIO MARC N GENERAL MANAGER DIVERSIFIED COMP SYS PO BOX 1098 GREELEY CO 80631 USA 
VAN AUSDALL C. R. MANAGER DATA PROCESSING COPCO 4905 LIMA STREET DENVER CO 80237 USA 
VAN BUITENEN PETER § SYSTENS DEDHAN MAKRO INTL CHURCHILL LAAN {4 So2F GUUTRECH NETHER 
VAN DEN KIEBCON AAD HEBLETT-PACKARD 90- EPHARTL {21 AMSTERDAM NETHER 
VAN KURAN PETER PRODUCT MANAGER HEWLETT-PACKARD $303 STEVENS CREEK BLVD SANTA CLARA CA 95050 USA 
VEENEMAN WILLIAM E SYSTEMS ANALYST PROCTER & GAMBLE CO 6105 CENTER HILL RD CINCINNATI OH 45220 USA 
VELLANKI RAO C SR PROGR/ANALYST HEWLETT-PACKARD 5303 STEVENS CREEK SANTA CLARA CA 95050 USA 
VILLA JR CHARLES J = PRESIDENT PANTECHNIC 5805 OCEAN VIEW DR OAKLAND CA 946418 USA 
VILLARREAL RAKON V TYMWARE CORP 44 WY JEFFERSON ST BROWNSVILLE 1X 78520 USA 
VIGHL KEN SATELLITE COMPUTING, INC PO BOX 2045 NORFOLK VA 235501 USA 
VOILES DUANE A SR SYSTEHS ANALYST ITT FINANCIAL PQ BOX 250 CHIPPEWA FALL WI 54729 USA 
WADE GERRY T PRODUCT SPECIALIST HEWLETT-PACKARD 5600 S DIC PARKWAY ENGLEBOOD CO 80110 USA 
WADE RON SYSTEMS ANALYST INFORMATION RESOURCES 7935 E PRENTICE AVE ENGLEWOOD CO 80114 USA 
WAGNER DAVID L MANAGER DATA PROCESSING MOORE & CO 300 & SPEER BLVD DENVER CO 80203 USA 
WALESKI JR WALTER L DIR INFO SYSTEHS MEDIA GENERAL INC S04 E GRACE ST RICHMOND VA 23219 USA 
WALLACE DARL L DIR EDUC COMP CTR WALLA WALLA COLLEGE COLLEGE PLACE WA 99324 USA 
WANDERHAN KENNETH A MANAGER COMPUTER SYS TITEL CORP { EMBARCADERO SAN FRANCISCO CA 94114 USA 
WARP CRAIG SHUGART ASS 435 OAKHEAD PARKWAY SUNNYVALE CA 94086 USA 
WATERS FRED INFO SYSTEMS MANAGER HERLETT-PACKARD SDD 16379 W BERNARDO DR SAN DIEGO CA 92127 USA 
WATSON DAVID J(CANCEL) ARMAMENT SYSTEMS INC 7i2-F N VALLEY ST ANAHETH CA 92632 USA 
WEBER WILLIAM SYSTENS ANALYST NPD RESEARCH, INC i$ VERBENA AVENUE FLORAL PARK NY 41604 USA 
WEBSTER THAD N MARKETING ENGINEER HEWLETT-PACKARD 2104 SUNSET AVE BOISE TD 83702 USA 
WEISMAN JOE MER SYSTEM DEVELOPMENT COMPUTERS FOR MARKETING 245 MARKET SAN FRANCISCO CA 94105 USA 
WEISS JAMES R VICE PRESIDENT E A KLEIN & ASSOC £000 SUPERIOR BLDG CLEVELAND OH 44414 USA 
WELSH ROD R SYSTEHS ANALYST DOHINION CONSTRUCTION S100 4 BENTALL CENTRE VANCOUVER BC V7XiBi CANADA 
WETTER WAYNE ALUM ROCK SCHOOL DIST 2930 GAY AVENUE SAN JOSE CA 95127 USA 
WHEELER J LADD DATA PROCESSING MANAGER C M FUNK & CO INC de N eND STREET BOX 1249 ~— LAFAYETTE IN 47902 USA 
WHEELER ROBIN C EDP MANAGER DOMTAR CONSTRUCTION ATRL 4 2004 UNIVERSITY ST MONTREAL QU H3AZAS CANADA 
WHIDBON ROY L SPECIALIST SOFTWARE NORTHERN TELECOM LTD 33 CITY CENTRE DRIVE HISSISSAUGA ON LSB2NS CANADA 
WHITE RUSS PRESIDENT R SHRIVER ASSOCIATES 126 LITTLETON ROAD PARSIPPANY NJ 07054 USA 
WICKHAH GAIL 0 MGR MARKETING SERVICES SYSTEMS RESEARCH INC 2400 SCIENCE PARKWAY QKEMOS HI 48864 USA 
WILKINSON JIM L GENERAL PARTNER UMPQUA DATA FACTORY de2 E ii EUGENE OR 97401 USA 
WILLARD JI HEWLETT-PACKARD 815 14 Sw LOVELAND CO B0S37 USA 
WILLIAMS RITA W SUPPORT ENGINEER HEWLETT-PACKARD 5303 STEVENS CREEK SANTA CLARA CA 95050 USA 
WILLIAMSON ROBERT M MFG DATA SYSTEMS MGR BOEING AEROSPACE CO PQ BOX 3999 HiS BN? SEATTLE WA 78124 USA 
WILGCK JAMES H SYSTEMS ANALYST FORD BOX 15998 SOUTHFIELD AT ROTUNDA DEARBORN MI 48i2i USA 
WILSON ROBERT L SALES HGR R SHRIVER ASSOCIATES {20 LITTLETON ROAD PARSITPANY NJ 07054 USA 
WINTON HUGH D P MANAGER HOERBIGER CORP 35 LUABER ROAD ROSLYN NY 11576 USA 
WOMBACHER ERNEST J © = CLERK OF DISTRICT COURT JOHNSON COUNTY IOWA 400 S CLINTON STREET TQWA CITY TA $2240 USA 
WONG DY-YEE DIRECTOR PROGRAMMING AUTOMATED ANALYSIS 3idS DONA SOFIA DR STUDIO CITY CA 74604 USA 
WOOD GLEN R MANUF SYS PROJECT LDR BOSE CORPORATION 400 MOUNTAIN ROAD FRAMINGHAM A 04764 USA 
WOOD WALTER A VICE PRESIDENT WOOD BROWN & ASSOCIATES 1673 CARLING SUITE 405 OTTAWA ON K2AiC4 CANADA 
WOOLPERT BRUCE W PRODUCT MANAGER HEWLETT-PACKARD 16399 W BERNARDO DR SAN DIEGO Ch 92127 USA 
WRIGHT DALE PANTECHNIC 5805 OCEAN VIEW DR OAKLAND CA 94618 USA 
WRIGHT JAKES C ELECTRICAL ENGINEER TEXAS MUN POWER AGENCY 2225 E RANDOL MILL RD ARLINGTON TX 76041 USA 
WRIGHT NORMAN B EXAMINING SYSTEMS COORD US CIVIL SERVICE COMM 4685 LOG CABIN DR MACON GA 31266 USA 
WRIGHT STEVE T MANAGER HOME OFFICE REPUBLIC MORTGAGE INS P QO BOX 2544 WINSTON SALEM NC 27182 USA 
YARBROUGH CHARLES VICE PRESIDENT COMPUTERS FOR MARKETING 215 MARKET SAN FRANCISCO CA 744105 USA 
YEO HARGE HEWLETT-PACKARD $304 STEVENS CREEK BLVD SANTA CLARA CA 75050 USA 


NAKE-13 


ATTENDEE BY NAME 


NAHE TITLE COMPANY ADDRESS CITY STATE ZIP COUNTRY 
YOUNG CHUCK W PROGRAMMER /ANALYST ASARCO INC P 0 BOX 98 HAYDEN AZ 85235 USA 
ZABOR ELIAS CUSTOMER RELATIONS HEWLETT-PACKARD 5303 STEVENS CREEK SANTA CLARA CA 95050 USA 


NAME-{4 © 


NAME 


KESSEL JIM (CANCELED) 
DUNCAN HANNAH F 
HANSEN WILLIAM R 
CURRERI JOSEPH A 
TANTZEN ROBERT G 
PIPER MICHAEL 
MONAHAN WILLIAH 
ERICSCON GORDY 0 
GREENE HARK L 
KENNEDY JACK 

SIMS RICH 

TAYLOR MIKE 
THOMPSON RANDY(CANCEL) 
SEVEBORG KARL E 
OSCARSSON HANS 0 
GREEN CHARLES R 
RICE ROBERT J 

BEACH JOHN R 
FERENSEN DANIEL E 
FRECH JOHN J 
ENGLANDER ALICE 
COOK LINDA L 
BAMBACH THOMAS H 
BHUTA MEHENDRA 
SCROGGS ROSS E 
WETTER WAYNE 

COOPER STEVEN Hi 
SCHWARTZ RICHARD T 
GRILLOS JOHN H 
TWYHAN DONALD R 
PAPPAS STEVE 

MAYHEW JOHN 
DAUGHERTY ROGER 
BEASLEY DAVID R 
FORSEE ANN T 
HARBRON THOMAS R 
MATHIAS TIMOTHY E 
SHEFFIELD REBECCA L 
FIELDS JAMES A 
LEWIS GERALD 

OLSON BRIAN 

DAVISON GERALD W 
KOLSTO ELLIOT & 
JOERGER STEVEN 6 
WATSON DAVID J(CANCEL) 
ENGLEBRECHT HICHAEL L 
EARLS JOHN D 

YOUNS CHUCK W 

KC SHANE MICHAEL 6 
BUELL DIANE 


CONFERENCE ATTENDEE LISTING INDEXED BY ATTENDEE COMPANY 


TITLE COMPANY ADDRESS CITY STATE ZIP COUNTRY 
INDIVIDUAL PQ BOX 124 CHAGRIN FALLS OH USA 
1601 LEWMBERG BLVD COLORADO SPRI CO 80945 USA 
SR SYSTEM CONSULTANT 5560 CAMERFORD DR DAYTON GH 45424 USA 
9142 EDMONSTON CT 202 GREENBELT MD 20770 USA 
CHIEF PROGRAMMING 658 STH TEST GROUP/AD HOLLOMAN AFB NM 88330 USA 
19601 NORDHOFFF NO RIDGE CA USA 
DEVELOPMENT HGR 3H SM CTR 223~SN ST PAUL KN 55001 USA 
ANALYST 3H CO OM CENTER BLDG 224-4N ST PAUL HN 5Si0% USA 
SUPERVISOR 3H CO SM CENTER BLDG 224-4N ST PAUL HN SSi0i USA 
MANAGER SYS & PROG A G BECKER SS WATER STREET NEW YORK NY 10041 USA 
EXEC V P ATI $532 S HILLCREST DR #3 DENVER CO USA 
PROGRARER ATI $552 S HILLCREST DR #3 DENVER CO USA 
ANALYST ATI 3952 S HILLCREST DR #3 DENVER C0 USA 
CIVIL ENGINEER AB BOFORS BOX 500 BOFORS 969020 SWEDEN 
HANAGER AB TRAV OCH GALOPP BOX 1733 STOCKHOLM SW 11487 SWEDEN 
DATA PROCESSING MANAGER ADAMS COUNTY SCHOOLS 602 E 64TH AVE DENVER CO 80229 USA 
SYSTEMS ANALYST ADAMS COUNTY SCHOOLS 602 E 64TH AVE DENVER CO 88229 USA 
HEAD OF OPERATIONS ADRIA LABORATORIES P 0 BOX 16529 COLUMBUS OH 43216 USA 
SYSTEMS ANALYST ADRIA LABORATORIES P 0 BOX 16529 COLUMBUS GH 43216 USA 
MANAGER OF STIC ADRIA LABORATORIES PO BOX 16529 COLUMBUS OH 43216 USA 
D P CONSULTANT ALICE ENGLANDER 1966 TITUS STREET SAN DIEGO CA 92410 USA 
DATA PROC SPEC/PREMR ALLEGHENY INTER UNIT SUITE 300 TWO ALLEGH CENTER PITTSBURGH PA {S2{2 USA 
PROJECT LEADER ALLIED CHEMICAL COPRI COLUMBIA RD MORRISTOWN NJ 07960 USA 
HGR SYSTEMS PLANNING ALLIED CHEMICAL CORP COLUMBIA RD MORRISTOWN NJ 07960 USA 
ALTERSABILITY 534 ROSAL AVENUE OAKLAND CA 94610 USA 
ALUM ROCK SCHOOL DIST 2930 GAY AVENUE SAN JOSE CA 95127 USA 
CONSULTANT AMERICAN MANAGEMENT SYSTEM S6i PILGRIM DRIVE SUITE D SAN MATEO CA 94404 USA 
PRINCIPAL AMERICAN MANAGEMENT SYSTEM S61 PILGRIM DRIVE SUITE D SAN MATEO CA 94404 USA 
VICE PRESIDENT AMERICAN HGHT SYSTENS Soi PILGRIM DRIVE SUITE D SAN MATEO CA 94404 USA 
DIRECTOR INFO SYSTEMS | AMERICAN RED CROSS {00 E MACK DETROIT MI 48201 USA 
AMERICAN SUBSCRIP TV 8383 WILSHIRE BLVD BEVERLY HILLS CA 902i USA 
AMERICAN SUBSRIP TV . 8383 WILSHIRE BLVD BEVERLY HILLS CA 90241 USA 
DIRECTOR DATA PROCESSING AMERICAN SUBSRIPT TV 8383 WILSHIRE BLVD BEVERLY HILLS CA 90211 USA 
ANDERSON COLLEGE ANDERSON IN 46041 USA 
INSTRUCTOR ANDERSON COLLEGE ANDERSON IN 46011 USA 
CHR COMPUTER SCIENCE ANDERSON COLLEGE ANDERSON IN 46011 USA 
ANDERSON COLLEGE ANDERSON IN 46011 USA 
STUDENT ANDERSON COLLEGE ANDERSON IN 46011 USA 
VICE PRESIDENT APEX DATA PROCESSING 950 SO EASTERN AVE LOS ANGELES CA 90022 USA 
VICE PRESIDENT APPLIED ANALYSIS INC 615 SOUTH FLOWER STREET LOS ANGELES (CA 90017 USA 
SENIOR ANALYST APPLIED ANALYSIS INC 645 SOUTH FLOWER STREET LOS ANGELES CA 90017 USA 
PROJECT MANAGER ARGONNE NATIONAL LAB 9700 SOUTH CASS AVENUE ARGONNE TL 60439 USA 
MANAGEMENT ENGINEER ARGONNE NATIGNAL LAB 9700 SCUTH CASS AVENUE ARGONNE IL 60439 USA 
ARMAMENT SYSTEMS INC 712-F N VALLEY ST ANAHETH CA 92804 USA 
ARMAMENT SYSTEMS INC 7i2-F N VALLEY ST ANAHETH CA 92632 USA 
RESEARCH ENGINEER ARKCO IKC 703 CURTIS STREET MIDDLETOWN OH 45043 USA 
STAFF ENGINEER ARTHUR A COLLINS INC 13601 PRESTON ROAD DALLAS TX 75240 USA 
PROGRAMMER/ANALYST ASARCO INC P 0 BOX 98 HAYDEN AZ 85235 USA 
ASSOC DIRECTOR COMPUTING ASSOC AMERICAN HED COLLEGE ONE DUPONT CIRCLE SUITE 280 WASHINGTON DC 20036 USA 
ANALYST/PROGRAHMER AURORA PUBLIC SCHOOLS 1085 PEORIA STREET AURORA CO 800% USA 


COMP ANY~i 


ATTENDEE BY COMPANY 


KLEVER JOHN ANALYST/PROGRAHMER AURORA PUBLIC SCHOOLS - 1085 PEORIA STREET AURORA CO 80011 USA 
PLEASANTS JOYCE B DIRECTOR DATA PROCESSING AURORA PUBLIC SCKOOLS {085 PEORIA STREET AURORA CO 80014 USA 
POLHEMUS JAN R MGR BUSINESS SYSTEMS AUSTIN INFORMATION SYS © 800 SW 46TH STREET RENTON WA 9805S USA 
CROW WILLIAM H MGR TECHNICAL SYSTEMS | AUSTIN INFORMATION SYS 450 WEST 4ST AVENUE ROSELLE NJ 07203 USA 
BOOTH BUD PRESIDENT AUTOMATED ANALYSIS 3i0S DONA SOFIA DRIVE STUDIO CITY CA 94604 USA 
WONG DY-YEE DIRECTOR PROGRAMMING AUTOMATED ANALYSIS Si05 DONA SOFIA DR STUDIO CITY CA 91604 USA 
NEAL RANDOLPH H PRESIDENT AUTOMATED BUSINESS SV 1649 W BROAD ST RICHMOND VA USA 
FLEET VICTOR W CONTROLLER B&S FINANCIAL SERVICES N COUNTY ROAD 25A PIQUA OH 45356 USA 
ROBERTS RICHARD A MGR SYSTEM & PROGRAMMING B&S FINANCIAL SERVICES = N COUNTY ROAD c5A PIQUA OH 45356 USA 
BROWN ROBERT A DATA PROCESSING SYSTEM MH B.K. SWEENEY HAN. CO, 6300 STAPLETON S. DR, DENVER CO B0216 USA 
BORDEN JOHN (CANCELED)SYSTEM MANAGER BALTIMORE GAS & ELEC BOX 1475 BALTIMORE MD 21203 USA 
BERGER ROBERT(CANCEL) ASSISTANT VICE PRESIDENT BANKERS TRUST CO i BANKERS TRUST PLAZA NEW YORK NY 40006 USA 
BERND WALTER ASSISTANT SYSTEM OFF BANKERS TRUST CO { BANKERS TRUST PLAZA NYC NY 10006 USA 
BLIESNER ROBERT G SYSTEMS ANALYST BCS PO BOX 24346 SEATTLE WA 98124 USA 
TIGELMAN ROBERT J = DATA PROCESSING HGR BEACON JOURNAL PUBL 44 E EXCHANGE ST AKRON GH 44328 USA 
HISKES GEORGE J DATA PROCESSING MANAGER BEALL?S DEPARTMENT ST 3923 MANATEE AVE W BRADENTON FL 33505 USA 
KOBUCHI KENT K PROJECT SUPERVISOR BECHTEL CORP P 0 BOX 3965 SAN FRANCISCO CA 94419 USA 
TRAPPE CLARENCE J SYSTEMS PROGRAMHER BECHTEL CORP 350 MISSION STREET SAN FRANCISCO CA 94405 USA 
PORTERFIELD STEPHEN T HP3000 SYSTEM MANAGER = BECHTEL CORPORATION P Q BOX 3945 SAN FRANCISCO CA 94119 USA 
RITCHIE CLIFFORD E OD P MANAGER BENEFIT TECHNOLOGY 900 LAFAYETTE STREET SANTA CLARA CA 95050 USA 
MULLER MEREDITH A = PROGRAMMER/ANALYST BOEING P Q BOX 3707 MS 3N-03 SEATTLE WA 98124 USA 
HANSON FRITZ HM LOGISTICS SYSTEM ENGINEE BOEING AERO SPACE CO PQ BOX 3999 SEATTLE WA 98124 USA 
PIERCE ANTHONY SR SYSTEMS ANALYST BOEING AEROSPACE CO PO BOX 5999 SEATTLE WA 98124 USA 
DRYNAN GILBERT © SYSTEMS DEV MANAGER BOEING AEROSPACE CO P 0 BOX 3i3 WOODINVILLE WA 98072 USA 
WILLIAMSON ROBERT M MFG DATA SYSTEMS MGR BOEING AEROSPACE CO PO BOX 3999 MiS 8Md9 SEATTLE WA 98124 USA 
CHIU WUYAN PROJECT ENGINEER BOEING COMM AIRPLANE CO =P 0 BOX 3797 36-02 SEATTLE WA 98124 USA 
JELLIFFE ARLENE i LEAD ENGINEER BOEING COMM AIRPLANE CO BOX 3707 SEATTLE WA 98124 USA 
RUTHERFORD CLYDE R © SUPV MSS COMPUTING BOEING COMMERCIAL AIR PO BOX 3707 M/S SF-09 SEATTLE WA 98124 USA 
HALSEY GREGG SYSTEM ANALYST BOEING COMPUTER SERVICE P OQ BOX 24346 SEATTLE WA 9Bi24 USA 
JOHNSON PAMELA SYSTEM ANALYST BOEING COMPUTER SERVICE P 0 BOX 24346 SEATTLE WA 98124 USA 
KANAGA MIKE SYSTEM ANALYST BOEING COMPUTER SERVICE ? 0 BOX 24346 SEATTLE WA 98124 USA 
KING GAIL PROJECT MANAGER BOEING COMPUTER SERVICE P O BOX 24346 SEATTLE WA 98124 USA 
MARSICEK R G BOEING COMPUTER SERVICE PO BOX 24346 SEATTLE WA 98124 USA 
HASSLINGER BOB SYSTEM ANALYST BOEING COMPUTER SERVICE P OQ BOX 24346 SEATTLE WA 98124 USA 
SURR T BOEING COMPUTER SERVICE PO BOX 24346 SEATTLE WA 98124 USA 
MURPHY DONALD C SYSTEM MANAGER BOEING COMPUTER SERVICES P O BOX 3707 H/S36-01 SEATTLE WA 98124 USA 
TAYLOR DAVID W SYSTEMS ANALYST BOEING COMPUTER SERVICES P O BOX 24346 SEATTLE WA 98124 USA 
IRIYE DICK SYSTEMS ANALYST BOETTCHER & CO 828 17TH STREET DENVER CO 80202 USA 
MEDD RANDY HP3000 SYSTEMS HGR BOETTCHER & CO 828 17TH STREET DENVER CO 80202 USA 
GUNBY D L (CANCELED) SUPV SYSTEM DESIGN & PRO BONAR & BEMIS LTD 2380 MC DOWELL ROAD BURLINGTON ON L7R4AL CANADA 
SEIFRIED W BRIAN SUPERVISOR SYSTEMS APPL BONAR & BEMIS LTD 2380 HC DOWELL ROAD BURLINGTON ON L7R4Ai CANADA 
DOWLING JAMES F DP OPERATIONS MANAGER BOSE CORPORATION 400 HOUNTAIN ROAD FRAMINGHAM MA 01701 USA 
WOOD GLEN R MANUF SYS PROJECT LDR BOSE CORPORATION 100 MOUNTAIN ROAD FRAMINGHAM © AA 04701 USA 
JARAMILLO JR NARCISO DB ADMIN BOURNS 1200 COLUMBIA AVE RIVERSIDE CA 92507 USA 
BRINOLE JIM BRANT COMPUTER SERVICES 615 BRANT STREET BURLINGTON ON L7R2G6 CANADA 
BLAND JOHN J SYSTEM DP ANALYST BROOKEHAVEN NATL LABOR Se BROGKEHAVEN AVE UPTON NY £41973 USA 
HAUDERT GERARD A OPERATIONS SUPERVISOR = BROOKEWAVEN NATL LABOR 32 BROOKEHAVEN AVE UPTON RY 11973 USA 
ROSS PATRICK D SR MEMBER TECHNICAL STAF BSL INC 495 JAVA SUNNYVALE CA 74086 USA 
KUKUDA, JR. JOHN VICE PRESIDENT BUSINESS COMPUTER CONCEPTS RD #1 BOX {31-B BURGETTSTOWN PA iS02i USA 
STARCK RICHARD E PRESIDENT BUSINESS COMPUTER CONCEPTS RD #i BOX 131-B BURGETTSTOWN PA iS02i USA 
FUNK CHRISTOPHER HM = PRESIDENT C 4 FUNK & CO INC 22 N ND STREET BOX i249 LAFAYETTE IN 47902 USA 


COMPANY-2 


ATTENDEE BY COMPANY 


NAHE TITLE COMPANY ADDRESS CITY STATE ZIP COUNTRY 
WHEELER J LADD DATA PROCESSING HANAGER C M FUNK & CO INC 2 N 2ND STREET BOX 1249 —_ LAFAYETTE IN 47902 USA 
PRITCHARD G BRIAN SR PROGRAMMER CANADA BLDG MATERIALS 55 INDUSTRIAL ST TORONTO ON M4G3W9 CANADA 
ONIZUKA SANDRA M SYSTEM MANAGER CANCER CENTER OF HI 1150 SOUTH KING ST HONOLULU HA 96814 USA 
SOKERS PETER CAPE ISLAND MARINA OCEAN DRIVE CAPE MAY NJ 08204 USA 
ALBARRAN RAUL F GTE DE PROCESAMIENTO CARDANES, SA APARTADO POSTAL S94 QUERETARO GR S9i = MEXICO 
HAISCH KEN R PRESIDENT CASCADE COMPUTER SYSTEHS I P 0 BOX 1666 LONGVIEW WA 98632 USA 
LUNDBERG ERIK SCIENTIFIC PROGRAMMER CASS UNIV OF WASH {107 NE 45TH ROOM 530 SEATTLE WA 98105 USA 
RAWSON TOM SYSTEMS PROGRAMMER CASS UNIV OF WASH 1107 NE 45TH ROOK S30 SEATTLE WA 98105 USA 
BALANDER HATTHEW J © SYSTEM PROGRAMMER CCSC 2640 PINE STREET ST LOUIS MO 63403 USA 
FARKAS GEORGE J SYSTEMS ANALYST CHRYSLER CORPORATION PO BOX £919 CIMS:4162725 DETROIT HI 48288 USA 
PIEKARSKI DAVID SUPUR COMPUTER UTILIZ CHRYSLER CORPORATION PO BOX £949 CIMS:4162725 DETROIT MI 48288 USA 
COPLIN ROBERT G D P DIRECTOR CITY OF KENNEWICK 210 W OTH KENNEWICK WA 99336 USA 
SULLIVAN EARLENE DATA COORDINATOR CITY OF KENNEWICK 210 W OTH KENNEWICK WA 99336 USA 
FRAGH EDWARD A SYSTEMS & PROG SUPVSR CITY OF SANTA MONICA 1685 HAIN STREET SANTA MONICA CA 90404 USA 
PREDMORE LIONEL A INFORMATION SYSTEMS SUPV CITY OF TEMPE Si & FIFTH BOX 5002 TEMPE AZ 85281 USA 
CHARD MILES & DATA PROCESSING MANAGER CLA-VAL CO PQ BOX 1325 NEWPORT BEACH CA 92663 USA 
BARKER RONALD E MANAGING DIRECTOR CLAYBROGK COMPUTING 70 BROOK ST LONDON WiY2HN ENGLAN 
MELVIN PETER § DIRECTOR GF MARKETING CHC ASSOCIATES 3 MARGARET ST BOSTON HA Oc02i USA 
CORDELLE YANN ENGINEER COGELOG 1 QUINCONCES GIF 91490 FRANCE 
FEHR GENE I D P MANAGER COHEN FURNITURE CO 336 SW ADAMS STREET PEORIA It 61602 USA 
ALEXANDER BYRON L CONSULTANT COLLIER-JACKSON ASSOC 1805 N WESTSHORE BLVD TAMPA FL 33607 USA 
JACKSON CHARLES W = PRESIDENT COLLIER-JACKSON ASSOC {805 N WESTSHORE BLVD TAMPA FL 33607 USA 
SLOAN DAVID L CONSULTANT COLLIER-JACKSON ASSOC 1805 N WESTSHORE BLVD TAMPA FL 33607 USA 
HUDSON MEL SYSTEMS ANALYST COLO DEPT OF EDUC eli E COLFAX DENVER CO 80203 USA 
ICKLER AL SENIOR PROGRAMMER COLO DEPT OF EDUC e0i E COLFAX DENVER CO 80203 USA 
PETERSON DONALD C HGR SYSTEMS ANALYST COLO DEPT OF HIGHWAYS 4201 E ARKANSAS DENVER CO 8d2e2 1)5A 
TEKLITS ROBERT § DATA MANAGEMENT SUPVR COLORADO DEPT EDUC e0i E COLFAX DENVER CO 80203 USA 
FRAME DARYL A SYSTEM MANAGER COMARCO INC ce7 W HUENEME ROAD OXNARD CA 93030 USA 
GOLDHANN ROGER SYSTEMS ANALYST COMARCO INC 2e7 W HUENEME ROAD OXNARD CA 93030 USA 
HWA CHIH § PRESIDENT COMPUSYS INC 789 SHERMAN 540 DENVER CO 80203 USA 
HARCHESE BUZZ SYSTEM MANAGER COMPUTER COMPOSITION SALES 2640 PINE ST ST LOUIS HO 63103 USA 
KORNEK KEN COMPUTER SERVICE DIVISION 19340 PRUNERIDGE AVE CUPERTINO CA 95044 USA 
RUSSELL JIM PRESIDENT COHPUTER SERVICES CORP 75 MANHATTAN DR #407 BOULDER CO 80503 USA 


WEISHAN JOE 
YARBROUGH CHARLES 


MGR SYSTEM DEVELOPHENT 
VICE PRESIDENT 


COMPUTERS FOR MARKETING 
COMPUTERS FOR MARKETING 


215 MARKET 
245 MARKET 


SAN FRANCISCO CA 94405 USA 
SAN FRANCISCO CA 94405 USA 


PUTEGNAT MICHAEL (CANC PRESIDENT CONTROL SYSTEMS 44 W JEFFERSON ST BROWNSVILLE TX 78520 USA 
RYAN GEOFFREY CONTROL SYSTEMS 44 U JEFFERSON ST BROXNSVILLE TX 78520 USA 
COOKSEY WILLIAK P PROGRAMMER/ANALYST COPECO 4905 LIMA STREET DENVER CO 80239 USA 
MEYER JAMES J COMPUTER OPERATIONS COPCO 4905 LIMA STREET DENVER CO 80239 USA 
VAN AUSDALL C. R, MANAGER DATA PROCESSING COPCO 4905 LIMA STREET DENVER CO 80239 USA 
JAMISON CARL L DATA PROCESSING MANAGER CRAIG HOSP RESEARCH OFFC 3460 SO CLARKSON ENGLEWOOD CO B0ii0 USA 
BUMMER DAVID C PRESIDENT DC DUMMER & ASSOCIATES 40 LK LUCERNE CL SE CALGARY AL T2J3HS CANADA 
TIER PAUL MARKETING MANAGER DC DUMMER & ASSOCIATES 40 LK LUCERNE CL SE CALGARY AL T2J3H8 CANADA 
SALINS GARY E DATA PROCESSING MANAGER DARE PAFCO, INC 11353 REED HARTHAN HY CINCINNATI OH 45040 USA 
LESSEY KEN W ASSOCIATE DATACOM 50 WEST STREET ST HELENS OR 9705i USA 
CHADWICK GRAHAM D COMPUTER MANAGER DE ZOETE D BEVAN THROGHORTON STREETS LONDON ENGLAN 
PARELLA MIKE PRESIDENT DECISION STRATEGY 708 THIRD AVENUE NEW YORK NY £0047 USA 
AUSTIN DAVID J ACTING DATA CENT COORD DENVER EMPLOY & TRAIN 142i ELATI STREET DENVER CO 80204 USA 
MOODY JERRY R SYSTEMS SUP DEPT OF ARMY BLDG 12500 ATTN DXRHC-C-C FORT LEE VA 238041 USA 


NC LEMORE JIM 
PASHAK JANES W 
BELLIS STEPHEN 


SYSTEMS MANAGER 
COMPUTER SPECIALIST 
PROGRAMMER 


DEPT OF ENERGY 4330 BROADWAY 
DEPT OF ENERGY 1353 BROADWAY 
DEPT OF FISHERIES & OCEANS BRANDY COVE 


OAKLAND CA USA 
OAKLAND CA 94161 USA 
ST ANDREWS = NB E0G2X0 CANADA 


COMPANY-3 


NAHE 


FAWKES GERALD 


GURUPRASAD CHOULGERE 


CAMERON LOUISE 
IMBEAU ANDRE 
CLEEVER KAREN J 
VALERTO HARC N 
JACKSON JOHN A 
HC MURRAY JACK ¥ 
WELSH ROD R 
WHEELER ROBIN C 
LUFT HARKUS F 
BAND. DENNIS 
BILMER , EARL 
FAIRCHILD JAMES B 


GOSSELIN JEANNINE G 


GUPTA RAMESH 
MINOR TERRY 
SMITH ROGER 
WEISS JAMES R 
LONG LYNDA J 
ANDERSEN SVEND 
BROWN DANA 
ECCLES SHARON L 
PRELLE JEAN 
HOORE ROBERT E 
PETERS HAROLD J 
FIGUEROA LUIS ¥ 
GOMEZ VICTOR 
HARBAUGH JERRY E 
CLABORN GEORGE H 
FISHER M ROGER 
LANCASTER HENRY C 
MILLER DANIEL J 
SWEARER DALE F 
SYMONDS GORDON R 
BENOIT WAYNE F 
CANTWELL FRANK E 
JONES THOMAS 0 
NEIBERGS GEORGE J 
FINE BRIAN T 
LOCKHEED ALLAN H 
UTTER ROGER S 
LEE HAROLD 
SHAULIS MICHAEL 
DELONG DAN G 


JOHNSTON CHARLES F 


BERAM ALFRED J 


GOLDBERG MICHAEL C 


KENNEDY DOUGLAS 
THORMAN BEN 
LOCHNER CHRIS 
WILOCK JAMES H 


TITLE 


PROGRAMMER 

DIRECTOR CORP SYSTEMS 
PROGRAMMER 

ACTING CHIEF 

SYSTEMS PROGRAMMER 
GENERAL MANAGER 
SYSTEMS ANALYST 

DP MANAGER 

SYSTEMS ANALYST 

EDP MANAGER 

SYSTEMS & PROG SUPRV 
TECHNICAL ANALYST 


SUPERVISOR OPERATIONS 
EDP MANAGER 

SYSTEMS & OR CONSULTANT 
SYSTEMS MGR 

DP MANAGER 

VICE PRESIDENT 

D P MANAGER 


ADMINISTRATOR INFO 
DATA PROCESSING MANAGER 
PROFESSOR 

PRESIDENT 

PRESIDENT 

GTE DE PROCESAMIENTO 
SYSTEM ENGINEER 

HGR DATA PROCESSING 
PROGRAMMER ANALYST 
MANAGER COMPUTER SERV 
V P ENG DEV & COMP SCI 
SYSTEMS ANALYST 
SYSTEMS ANALYST 

HEAD COMPUTER APPLIC 
MANAGER PRODUCT DEV 
DIRECTOR PRODUCT DEV 
EXEC V P 

IS MANAGER 

TECH STAFF 


COMPUTER APPLICATIONS 


PROGRAMMER 
DATA PROCESSING MANAGER 


COMPANY 


ADDRESS 


DEPT OF FISHERIES & OCEANS BRANDY COVE 


DEPT OF SUPPLY CANADA 
DEPT REG ECO EXPANSION 
DEPT REG ECO EXPANSION 


ii LAURIER 
200 RUE PRINCIPAL 
200 RUE PRINCIPAL 


DEPT REGIONAL ECONOMIC EXP 604 SPADINA CRES E 


DIVERSIFIED COMP SYS 
DOMINION CONSTRUCTION 
DOMINION CONSTRUCTION 
DOMINION CONSTRUCTION 
DOMTAR CONSTRUCTION ATRL 


DOMTAR CONSTRUCTION MTRLS 


DOMTAR INC 
DOMTAR INC 
DOMTAR INC CHEM GROUP 


~DOHTAR INC CHER GROUP 


DOMTAR INC CHEM GROUP 
DONNELLY MIRRORS INC 
DONNELLY MIRRORS INC 
E M KLEIN & ASSOC 
EST 

EBI COMPANIES 

EBI COMPANIES 
ECKANKAR 


PO BOX 1098 

3i00 3 BENTALL CENTRE 
3400 3 BENTALL CENTRE 
3100 3 BENTALL CENTRE 
2001 UNIVERSITY ST 

2004 UNIVERSITY ST 

39S DE MAISONNEUVE BLVD 
395 DE MAISONNEUVE BLVD 
BP 7ei2 

BP 7ei2 

BP 7212 

49 W SRD ST 

49 W SRD ST 

1000 SUPERIOR BLDG 

765 CALIFORNIA STREET 
{290 NORTH FIRST ST 
1290 NORTH FIRST ST 

{20 SCOTT DRIVE 


ECOLE SUPERTEURE DE COMMER 23 ROUTE DE DARDILLY 


EDUCATIONAL COMPUTER SYS 


{343 KEMPER RD 


EDUCATIONAL SOFTWARE PRODU 9 GEORGETOWN CIRCLE 


EJES TRACTIVOS SA 
ELECTRONIC DATA SYS 
ELFAB 

ENVIRONMENTAL ELEMENTS 
ENVIRONMENTAL ELEMENTS 
ENVIRONMENTAL ELEMENTS 
ENVIRONMENTAL ELEMENTS 
ENVIRONMENTAL ELEMENTS 
ENVIRONMENTAL HEALTH 
EPSILON DATA MGHT 
EPSILON DATA MGHT 
EPSILON DATA RGHT 
ESB~EXIDE 

ESL INC 

EXXON MINERAL CO USA 
EXXON NUCLEAR CO 


APARTADO POSTAL 14820 
ONE WAYNE MALL 
4200 WYLEY POST 
3700 KOPPERS ST 
3700 KOPPERS ST 
3700 KOPPERS ST 
3700 KOPPERS ST 
3700 KOPPERS ST 
TUNNEYS PASTURE 

24 NE EXECUTIVE PK 
24 NE EXECUTIVE PK 
24 NE EXECTIVE PK 
{04 GIBRALTOR RD 
495 JAVA DR 

604 JEFFERSON 
777-106 TH AVE NE 


FAIRFAX CNTY PUBLIC SCHOOL DATA SERVICES DIVISION 
FAIRFAX CNTY PUBLIC SCHOOL DATA SERVICES DIVISION 


FEDERAL HOME LOAN BANK 
FERRIS BSSCHER LOHMA 


EXECUTIVE VICE PRESIDENT FINANCIAL DATA PLANNING 


PRESIDENT 

VICE PRESIDENT 
ASST D P HER 
SYSTEM HANASER 
SYSTENS ANALYST 


FINANCIAL DATA PLANNING 
FINANCIAL DATA PLANNING 
FLINT INDUSTRIES INC 
FORD BOX 15998 

FORD BOX iS99B 


600 STEWART ST 

339 E i6TH STREET 
2670 TIGERTAIL AVENUE 
2670 TIGERTAIL AVENUE 
2670 TIGERTAIL AVENUE 
P 0 BOX 490 
SOUTHFIELD AT ROTUNDA 
SOUTHFIELD AT ROTUNDA 


ATTENDEE BY COMPANY 


CITY STATE ZIP COUNTRY 


ST ANDREWS 
HULL 

HULL 

HULL 
SASKATOON 
GREELEY 
VANCOUVER 
VANCOUVER 
VANCOUVER 
HONTREAL 
MONTREAL 
MONTREAL 
MONTREAL 
MONTREAL 
MONTREAL 
MONTREAL 
HOLLAND 
HOLLAND 
CLEVELAND 


NB E0G2X0 CANADA 
QU CANADA 
QU KiAOM4 CANADA 
QU KiA0H4 CANADA 
SA S7K3G8 CANADA 
CO 80634 USA 

BC V7XiBi CANADA 
BC V7XiBi CANADA 
BC V7X{Bi CANADA 
QU H3AZA6 CANADA 
QU HSAZA6 CANADA 
QU JéK2E6 CANADA 
QU JaK2E6 CANADA 
QU H3C3H3 CANADA 
QU H3C3M3 CANADA 
QU H3C3M3 CANADA 
MI 49423 USA 

HI 49423 USA 

QH 44414 USA 


SAN FRANCISCO CA 94108 USA 


SAN JOSE 
SAN JOSE 
HENLO PARK 
ECULLY 
CINCINNATI 
1QWA CITY 
MEXICO 
WAYNE 
ADDISSON 
BALTIMORE 
BALTIMORE 
BALTIMORE 
BALTIMORE 
BALTIMORE 
OTTAWA 
BURLINGTON 
BURLINGTON 
BURLINGTON 
HORSHAM 
SUNNYVALE 
HOUSTON 
BELLEVUE 
SPRINGFIELD 
SPRINGFIELD 
SEATTLE 
HOLLAND 
MIAMI 
MIAMI 
MIAHI 
TULSA 
DEARBORN 
DEARBORN 


CA 95ii2 USA 
CA 95112 USA 
CA USA 
FRANCE 
OH 45246 USA 
1A 52240 USA 
DF 44820 MEXICO 
NJ 07470 USA 
TX 75001 USA 
AD 21227 USA 
MD 21227 USA 
MD 21227 USA 
MD 21227 USA 
HD 21227 USA 
ON KiA0L2 CANADA 
MA 04803 USA 
HA 01803 USA 
RA 01803 USA 
PA 19044 USA 
CA 94086 USA 
TX 77601 USA 
¥A 98009 USA 
VA 22451 USA 
VA 22151 USA 
WA 98101 USA 
HI 49423 USA 
FL 33133 USA 
FL 33133 USA 
FL 33133) USA 
OK 74181 USA 
MI 48121 USA 
HI 48i2i USA 


COMPANY-4 


NAHE 


ARTHOFER ROBERT J 
ONYX ROBERT P 
FRATUS WILLIAM P 
KELLY KENT 

NC AFEE WILLIAM K 
DROBNY RONALD G 
BERGOLD THEODORE A 
SJOGREN DAVID R 
MATT RICHARD G 
HEINZ MICHAEL J 
FAIRFIELD STEVE 
EDWARDS BETH 
BOTTEGAL THOMAS ¥ 
LEE LANCE 

ROBINSON JOEL H 
HATCH JAMES L 
JACOB HARRY 0 
BEDET ROB 

DELMAGE A R(CANCELED) 
JOHNSON BOB 
THOMPSON JIM 

ADANS RAY 

BILLS DANIEL G 
HALACHOWSKI ERNEST S 
PICK Y MICHAEL 
BEADLE, JR RAY 
BINDEWALD THOMAS L 
TONNESEN LARRY D 
BYFORD WENDY K 
KENFIELD JOHN E 
JACKSON ELAINE T 
BENNETT WALTER W 
HUTTUNEN HEIKKI J 
VAN DEN KIEBOOM AAD 
BUTLER KEITH C 
CORRELL STEVEN 
FREED JAMES F 
STARK JOHN A 

HOXE ROBERT D 
LOWRY GLEN H 
THOMASSON GARY 
MEBSTER THAD N 
CARRUTHERS ALEX R 
ENGBERG TONY I 
GRUBER DIANNE 
DOUGLAS GORDON R 
JOHNSTONE SHIRLEY J 
LAIR STEVE 

MORAIN OLEN 

TARENS MICHAEL R 
DONHAM DAN 

JOHNSON RON H 


TITLE 


COMPANY 


DATA PROCESSING MANAGER FOSECO INC 


D P OPER MANAGER 


PRESIDENT 

SYSTEM MANAGER 
MANAGER INFO-SYSTEMS 
SYSTEM SPECIALIST 
HARDWARE PLANNER 
SUPERVISOR, TECH SERVS 
INFO SYSTEMS ANALYST 
INFO SYSTEMS ADM 


SENIOR PROGRAMMER 
HGR INFORMATION SYS 
DIRECTOR 


KER DISTRIBUTED SYSTEMS 


CONTROLLER 

PRESIDENT 

CONTROLLER 

RESEARCH COMPUTER HGR 
SR SYSTEMS ANALYST 
SR TECHNICAL ANALYST 
SYSTEMS HANAGER 
SYSTEMS ENGINEER 
INFO SYS MANAGER 
MINICOMPUTER ANALYST 
DEV INFO COORDINATOR 
ADP MANAGER 


ENGINEER 

ENGINEER 

INFO SYSTEHS MANAGER 
SYSTEMS ENGINEER 
MARKETING MANAGER 
INFO SYS MANAGER 

FAC INFO SYS MANAGER 
HARKETING ENGINEER 
SYSTEHS ENGINEER 
SYSTEMS ENGINEER 


FACILITY INFO SYS MGR 


FOSECO INC 
FUTURA INC 

FUTURA INC 

FUTURA INC 

GATES & SONS 

GATX LEASING 
GENERAL HILLS 
GENERAL HILLS INC 
GENERAL MILLS, INC 
GENERAL TELEPHONE 
GENERAL TELEPHONE-HI 


ADDRESS 


20200 SHELDON ROAD 
20200 SHELDON ROAD 
1714 § CONGRESS 
1714 § CONGRESS 
{714 S CONGRESS 

90 SOUTH FOX 

ONE EMBARCADERO CNTR 
PO BOX {443 

9200 WAYZATA BLVD 
PO BOX 1113 

455 E ELLIS ROAD 
455 E ELLIS ROAD 


GEORGE WASHINGTON UNIVERSI 725 23 STREET NW 


GECRGE WIMPEY CANADA 
GEORGE WIMPEY CANADA 

GH SAGINAW DATA CENTER 
GH SAGINAW DATA CENTER 
GOV'T OF N W TERRITORIES 
GOV'T OF NW TERRITORIES 
GOV'T OF NW TERRITORIES 
GOW’T OF N W TERRITORIES 
GRACELAND COLLEGE 
GRANVILLE-PHILLIPS CO 
GRANVILLE-PHILLIPS CO 
GRUMMAN AERO SPACE CORP 
GRUMMAN AEROSPACE 

GTE DATA SERVICES 
GUARDSMAN LIFE INS 

H P 

H-P SANTA ROSA DIV 
HARTFORD INSURANCE 
HARVARD 

HELSINKI SCHOOL OF ECON 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 


SOFTWARE RELIABILITY ENG HEWLETT-PACKARD 


5 E DSITRICT MGR 
COMPUTER SERVICES DIV 
REGIONAL MKTG ENGINEER 
SYSTEHS ENGINEER 
DISTRICT SALES MGR 


HEWLETT-PACKARD 
HEMLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 


80 NORTH QUEEN ST 
80 NORTH QUEEN ST 
3700 HOLLAND ROAD 
3700 HOLLAND ROAD 


S675 ARAPAHOE 

5675 ARAPAHOE 

A 08-35 

SOUTH OYSTER BAY ROAD 
FIRST FINANCIAL TOWER 
1025 ASHWORTH ROAD 
275 HYMUS BLVD 

1400 FOUNTAIN GROVE PK 
HARTFORD PLAZA 
HOLYOKE 

RUNEBERGINK 14-16 

90- EPHARTL 124 

RT 44 & STAR ROAD 

RT 44 & STAR ROAD 
ROUTE 414 

1203 {14TH SE 

DISC MEMORY DIVISION 
PO BOX 45 

PO BOX 46 

2104 SUNSET AVE 

210 7228 FISHER ST 
{9855 GIESENDORFER RD 
1900 GARDEN GODS ROAD 
41000 WOLFE ROAD 
19400A HOMESTEAD RD 
19310 PRUNERIDGE RD 
19310 PRUNERIDGE AVE 
49400 HOMESTEAD RD 
5600 DIC PKWY 

5600 DIC PKWY 


ATTENDEE BY COMPANY 


CITY STATE ZIP COUNTRY 


BROOKPARK 
BROOKPARK 
AUSTIN 
AUSTIN 
AUSTIN 
DENVER 


GH 44142 USA 
GH 444142 USA 
TX 78704 USA 
TX 78704 USA 
TX 78704 USA 
CO 80226 USA 


SAN FRANCISCO CA 94111 USA 


MINNEAPOLIS 
MINNEAPOLIS 
MINNEAPOLIS 
MUSKEGON 
KUSKEGON 
WASHINGTON 
TORONTO 
TORONTO 
SAGINAW 
SAGINAW 
YELLOWKNIFE 
YELLOWKNIFE 
YELLOWKNIFE 
YELLOWKNIFE 
LAMONI 
BOULDER 
BOULDER 
BETHPAGE 
BETHPAGE 
TAMPA 


HN 55440 USA 
HN $5426 USA 
HN 55440 USA 
HI 49443 USA 
MI 49443 USA 
DC 20052 USA 
ON MBZ2C9 CANADA 
ON M8Z2C9 CANADA 
HI 48605 USA 
AI 48605 USA 
NW XOELHO CANADA 
NW XOE{HO CANADA 
NW XQE{HO CANADA 
NW XOELHO CANADA 
TA 50140 USA 
CO 80303 USA 
CO 80303 USA 
NY 141714 USA 
NY USA 
FL 33611 USA 


WEST DESHOINE IA 50265 USA 


PTE CLAIRE 
SANTA ROSA 
HARTFORD 
CAMBRIDGE 
HELSINKT 
AMSTERDAM 
AVONDALE 
AVONDALE 
AVONDALE 
BELLEVUE 
BOISE 
BOISE 
BOISE 
BOISE 
CALGARY 
COLFAX 


Qu CANADA 
CA 95404 USA 
CT 06033 USA 
HA 02438 USA 
002005 FINLAN 
NETHER 
PA 19311 USA 
PA 19314 USA 
PA 19341 USA 
WA 98004 USA 
ID 83707 USA 
ID 83707 USA 
ID 83707 USA 
ID 83702 USA 
AL TeH2H8 CANADA 
CA 95713 USA 


COLORADO SPRI CO 80907 USA 


CUPERTINO 
CUPERTINO 
CUPERTINO 
CUPERTINO 
CUPERTINO 
ENGLEWOOD 
ENGLEWOOD 


CA 95044 USA 
CA 95014 USA 
CA 95014 USA 
CA 95014 USA 
CA 95014 USA 
CO 80110 USA 
CO 80410 USA 


CONPANY-§ 


NAHE 


KUEHNER WARREN 
WADE GERRY T 
FRENCH DEBORAH J 
JOHNSON GARY L 
SQUIRES JI 
AMBLER BURT 
HALLOCK JIM 
KASUN ELLEN 
LEMLEY JOHN 
WILLARD JTH 
SCHWARTZ RICK A 
CASEY CHRIS J 


SCHWARZ RAYMOND T 


SLATER TED 
GUERRERO JORGE 
WOOLPERT BRUCE W 
GROFF JAMES R 
OSBORNE LEE K 


JORGENSON DANIEL 4 


ALDERETE JOHN R 
BARHAN MARC 
BIRKWOOD ILENE H 
CELLI JOHN 
COUCH JOHN D 
CROCKETT DAVID 
GARDNER LYNN 
GIMPLE BILL 
GLOSS GREGORY C 
GRIFFIN MARY 
HATCHER BETH 
HENRY WENDELL A 
KAM POLLY 
KERNKE JUTTA C 
LARSON ORLAND J 
LEVIN GREGG B 
LEWIN ROBERT E 
HC CRACKEN ED 
HENOLD BEN 

PAGE JOHN 
RIEGER DENNIS E 
SMITH HOWARD J 


SPALDING KENNETH G 


TEMBROCT JOE R 
VAN KURAN PETER 
VELLANKT RAO C 
WILLIAMS RITA W 
YEO HARGE 

ZABOR ELIAS 
CLIFTON ROY A 
COOPER PAUL D 


FARRAGHER MICHAEL J 


D’ ANGELO RICHARD J 
HUTCHISON PHILIP L 


THLE 


S E DISTRICT HGR 
PRODUCT SPECIALIST 
PROGRAMMER/ANALYST 
INFO SYSTEMS HGR 
SYSTEMS ENGR 


DIST CE MANAGER 
SYSTEMS SUPPORT HGR 
MINI-OPERATIONS MGR 
SALES REP 

S E INSTRUCTOR 
PRODUCT MANAGER 
PRODUCT MANAGER 
DEVELOPMENT ENGINEER 
PRODUCT SUPPORT MGR 
PROJECT MANAGER 
DEVELOPMENT ENGINEER 
S E MANAGER 

BUS & AKTING HGR 
SECTION MANAGER 

PRG MGR HP300 SYS 
CUSTOMER RELATIONS 

R & D MGR HP300 PRE 
COBOL PROJECT MANAGER 
MARKETING ENGINEER 


MEMEBERT OF TECH STAFF 
PROGRAMMER/ANALYST 
PRODUCT MANAGER 

IMAGE PRODUCT MANAGER 
DESIGN ENGINEER 

THIRD PARTY PGH HER 
GEN HGR G 5 D 

S E DISTRICT HER 
PROJECT MANAGER 
PRODUCT MANAGER - HPE 
LAB MANAGER 
DEVELOPMENT ENGINEER 
DP MANAGER 

PRODUCT MANAGER 

SR PROGR/ANALYST 
SUPPORT ENGINEER 


CUSTOMER RELATIONS 
MPE SUPPORT MANAGER 
SYSTEMS ENGINEER 
PROG SUPERVISOR 
SYSTEMS ENGINEER 
PRODUCT ENGINEER 


COMPANY 


HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEULETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 
HEWLETT-PACKARD 


HEWLETT-PACKARD CO 
HHEWLETT-PACKARD 


ADDRESS 


S600 DIC PKWY 

5600 S DTC PARKWAY 

3400 E HARMONY ROAD 
3860 HARMONY ROAD 

1430 € ORANGETHORPE 

B15 14 SW 

BiS 14 SW 

815 14 SW 

B15 14 SW 

81S 14 SW 

6877 GOREWAY DRIVE 

1504 PAGE MILL RD 

{S04 PAGE MILL RD 

10691 SHELLBRIDGE WAY 

4 CHOKE CHERRY RD 

{6399 W BERNARDO DR 
{342 STAYNER RD 

{046 S WINCHESTER #7 
5303 STEVENS CREEK BLVD 
$303 STEVENS CREEK 

S303 STEVENS CREEK 

$303 STEVENS CREEK BLVD 
5303 STEVENS CREEK 

5303 STEVENS CREEK 

5303 STEVENS CREEK 

$303 STEVENS CREEK BLVD 
S303 STEVENS CREEK 

S303 STEVENS CREEK 

5303 STEVENS CREEK BLVD 
6304 STEVENS CREEK BLVD 
S303 STEVENS CREEK 

S304 STEVENS CREEK BLVD 
S303 STEVENS CREEK BLVD 
5303 STEVENS CREEK BLVD 
S303 STEVENS CREEK 

5303 STEVENS CREEK 

5303 STEVENS CREEK 

5303 STEVENS CREEK 

5303 STEVEN CREEK 

S303 STEVENS CREEK BLVD 
5303 STEVENS CREEK 

5303 STEVENS CREEK 

S304 STEVENS CREEK 

S303 STEVENS CREEK BLVD 
5303 STEVENS CREEK 

$303 STEVENS CREEK 

S304 STEVENS CREEK BLVD 
$303 STEVENS CREEK 

972 BUCKEYE CT 

4410 5 100 E AVE 

{75 WYMAN STREET 


32 HARTWELL AVE 
3400 E HARMONY RD 


ATTENDEE BY COMPANY 


CITY STATE ZIP COUNTRY 


ENGLEWOOD 
ENGLEWOOD 
FORT COLLINS 
FORT COLLINS 
FULLERTON 
LOVELAND 
LOVELAND 
LOVELAND 
LOVELAND 
LOVELAND 
MISSISSAUGA 
PALO ALTO 
PALO ALTO 
RICHMOND 
ROCKVILLE 
SAN DIEGO 
SAN JOSE 
SAN JOSE 
SANATA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SANTA CLARA 
SUNYVALE 
TULSA 
WALTHAM 


LEXINGTON 
FORT COLLINS 


CO 80444 USA 
CO 80110 USA 
CO 98525 USA 
CO 80524 USA 
CA 92631 USA 
CO 80537 USA 
CO 80537 USA 
CO 80537 USA 
CO 80537 USA 
CO 80537 USA 
ON LAViH® CANADA 
CA 94304 USA 
CA 94304 USA 
BC V6X2W7 CANADA 
MD 26850 USA 
CA 92127 USA 
CA 95i2i USA 
CA 95128 USA 
CA 95050 USA 
CA 95050 USA 
CA 75850 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95850 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 95050 USA 
CA 94086 USA 
OK 74445 USA 
HA 02154 USA 


MA 02473 USA 
CO 80525 UGA 


COMPANY—6 


RANE 


JOHNSON RAYMOND E 
HANIES RALPH G 
CALLANAN BILL 


TITLE 


HP 3000 PRGM SERV HGR 
CUSTOMER RELATIONS 
S E SUPERVISOR 


MARQUEZ MATEO(CANCEL) FIELD ENGINEER 


COVITT MARC L 


LAW JACK 


PRILL BOB (CANCELED) 


WATERS FRED 


BORG CHARLES J 
LASLEY MICHAEL A 
TATHAN PAUL E 
HERBEL ERIC § 


WINTON HUGH 


KLEIN THOMAS C 

SOCIE LARRY J 

BRUNK GREGG A 

KRIGER WINSTON A 
SMITH JR HARRY R 
BARTOLI JR CHESTER T 


CHEN CHANG L 


HINES RELLA # 
BECHER ANTHONY H 
GALUSKY DIANE M 
GULICK LLOYD R 
MECHAM DOUGLAS J 
THEISSEN WILHELM J 
TRAPP ROBERT E 


GRIFFIN RICK 


MILLER STEPHEN L 
PETTERCHAK JOHN J 
COLDREN J DAVID 
HATER EDWARD F 


MAY NORMAN F 


GRADY MICHAEL K 
QUELLETTE MARC E 
BRODOWSKT RICHARD E 


HALL CRAIG T 


CAMARILLO MARIO R 
MAGDALENO JESUS 


STOVER RAY J 
BEMAN ROGER 
WADE RON 


KLEIN JAMES D 
BRYDEN WILLIAH 
HOORE GEORGE £ 


HACHIN JOHN 


GRICE FRANK H 

RAUH JOSEPH E 
SYNOLD PRISCILLA J 
WANDERMAN KENNETH A 
RERSHON ROBERT C 
VOILES DUANE A 


TECHNICAL SUCS HGR 
DATABASE ADMINSTRATOR 
OPERATIONS HANAGER 
INFO SYSTEMS MANAGER 
SYSTEMS PROGRAMMER 
HIS MANAGER 

SYSTEMS MANAGER 
MEDICAL SYS ANALYST 
D P MANAGER 

MGR INFO SYSTEMS 
PROGRAMMER 


ADMINSTRATIVE ASSISTANT 


HER TECHNICAL SALES 
DIRECTOR, COMPUTER CTR 
OPERATIONS SUPERVISOR 
SYSTEM ANALYST 
EXECUTIVE DIRECTOR 
HEAD C.A.M. ENG 
SUPERVISOR APPL DEV 
COMPUTING SPECIALIST 
SYSTEMS COORDINATOR 
MANAGER BUSINESS SYST 
TEST ENGINEER 
PRESIDENT 

COMP PROD SUPYR II 
INFO SYST EXECUTIVE 
ASSOCIATE DIRECTOR 
INFO SYSTEMS EXECUTIVE 
SR SYSTEMS ANALYST 
SYSTEMS CONSULTANT 
SOFTEWARE SPECIALIST 
DIRECTOR INFO SYSTEMS 
PRESIDENT 

DIR DE SISTEMAS 

GTE DE PROYECTOS 


V P MARKETING 
SYSTEMS ANALYST 
SYSTEMS PROGRAMMER 
PRESIDENT 

OPERATIONS MANAGER 
MANAGING PARTNER 
PRESIDENT 

TECHNICAL SHOWMAN 
MANAGER TECHNICAL SPT 
MANAGER COMPUTER SYS 
PROJECT MANAGER 

SR SYSTEMS ANALYST 


COMPANY 


HEWLETT-PACKARD GSD 
HEWLETT-PACKARD GSD 
HEWLETT-PACKARD LTD 
HEWLETT-PACKARD MEXICO 
HEWLETT-PACKARD SDD 
HEWLETT-PACKARD SDD 
HEWLETT-PACKARD SDD 
HEWLETT-PACKARD SDD 
HEWLETT-PACKARD SRD 
HINDERLITER 

HHO SYSTEMS INC 
HOECHST-ROUSSEL PHARM 
HOERBIGER CORP 
HOOVER-NSK BEARING 
HOOVER-NSK BEARING 
HOUSTON INSTRUMENT 
HOUSTON INSTRUMENT 
HOWARD COMMUNITY COLLEGE 
HP AVONDALE DIV 

HP AVONDALE DIV 

HP GEN SYS USERS GROUP 
HUGHES AIRCRAFT CO 
HUGHES AIRCRAFT CO 
HUGHES AIRCRAFT CO 
HUGHES AIRCRAFT CO 
HUGHES AIRCRAFT CO 
HUGHES AIRCRAFT CO 
IC § SERVICES, INC 
IL DEPT OF CORRECTION 
IL DEPT OF CORRECTION 
IL LAW ENFORCEMENT CO 
IL LAW ENFORCEMENT CO 
IL LAW ENFORCEMENT CO 
ILLINOIS DEPT LAW & ORDER 
INCO LIMITED 

IND PRESS-TELEGRAM 
INFO TRONIC SYSTEMS 
INFORHATICA DESC, SC 
INFORMATICA DESC, SC 
INFORMATION RESOURCES 
INFORMATION RESOURCES 
INFORMATION RESOURCES 
INFORMATION TERMINALS 
INLAND SYSTEMS ENGR 
INTERACTIVE APPL INC 
INTERCOMP SERVICES 
INTERTEC 

ISSCO 

ISSCO 

ITEL CORP 

ITT FINANCIAL 

ITT FINANCIAL 


ADDRESS 


$503 STEVENS CRK BLVD 
5303 STEVENS CREEK BLUD 
KING ST LANE WINNERSH 


ATTENDEE BY COMPANY 


CITY STATE ZIP COUNTRY 


SANTA CLARA 
SANTA CLARA 


WOKINGHAM BER 


AVENIDA PERIFERICO SUR 6504 TEPEPAN 


16399 W BERNARDO DR 
16599 W BERNARDO DR 
16399 W BERNARDO DR 
16399 W BERNARDO DR 
1400 FOUNTAIN GROVE PK 
1240 N HARVARD 

{235 RIVERSIDE 

RT 202-206 NORTH 

35 LUMBER ROAD 

5400 S STATE RD 

5400 S STATE RD 

8500 CAMERON ROAD 
8500 CAMERON ROAD 
LITTLE PATUXENT PKWY 
ROUTE 44 & STARR RD 
ROUTE 41 & STARR RD 
PO BOX 18813 

BOX 3340 BLDG 607/8329 
PQ BOX 3310 607/E331 
PQ BOX 3310 607/E331 
PQ BOX 3340 601-4249 
PO BOX 3340 607/338 
1904 W MALVERN AVE 
eigi W EULESS BLVD 
200 W WASHINGTON 

200 N WASHINGTON 

120 S RIVERSIDE PLAZA 
120 S RIVERSIDE PLAZA 
120 S RIVERSIDE PLAZA 
200 W WASHINGTON 

i FIRST CANADIAN PL 
604 PINE AVE 

449 HOWARD AVE 

THIERS 248 ANZUREZ 
THIERS 248 ANZUREZ 
4905 LIMA 

7935 E PRENTICE 

7955 E PRENTICE AVE 
323 SOQUEL WAY 

424 BEVERLY DR 

505 HAMILTON AVE #103 
459 COLLINS STREET 
2625 PARK BLVD 

4186 SORRENTO VALLEY BLVD 
4186 SORRENTO VALLEY BLUD 
1 EMBARCADERO 

P 0 BOX 250 

PQ BOX 250 


SAN DIEGO 
SAN DIEGO 
SAN DIEGO 
SAN DIEGO 
SANTA ROSA 
TULSA 

FT COLLINS 
SOMERVILLE 
ROSLYN 

ANN ARBOR 
ARN ARBOR 
AUSTIN 
AUSTIN 
COLUMBIA 
AVONDALE 
AVONDALE 
BALTIMORE 
FULLERTON 
FULLERTON 
FULLERTON 
FULLERTON 
FULLERTON 
FULLERTON 
EULESS 
SPRINGFIELD 
SPRINGFIELD 
CHICAGO 
CHICAGO 
CHICAGO 
SPRINGFIELD 
TORONTO 
LONG BEACH 
HOLLAND 
MEXICO 
REXICO 
DENVER 
ENGLEWOOD 
ENGLEWOOD 
SUNNYVALE 


~ REDLANDS 


PALO ALTO 
MELBOURNE 
PALO ALTO 
SAN DIEGO 
SAN DIEGO 


CA 
CA 95050 


X0 22 
CA 92127 
CA 92127 
CA 92127 
CA 92127 
CA 95404 
QK 74115 
CO 80521 
NJ 08876 
NY 41576 
MI 48106 
HI 481064 
TX 78753 
TX 78753 
HD 21044 
PA i93i4 
PA i934f 
MD 21240 
CA 92654 
CA 92634 
CA 92634 
CA 92634 
CA 92654 
CA 92634 
TX 

IL 

IL 

IL 60606 
IL 60606 
IL 60686 
IL 


USA 
USA 
ENGLAN 
MEXICO 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 


ON MSXiC4 CANADA 


CA 

MI 49423 
DF 

DF 

CO 

CO 80iii 
CO 804i 
CA 94086 
CA 92373 
CA 94301 
VI 3000 
CA 94306 
CA 9eiei 
CA Piel 


SAN FRANCISCO CA 94144 
CHIPPEWA FALL WI 54729 
CHIPPEWA FALL WI 54729 


USA 
USA 
MEXICO 
MEXICO 
USA 
USA 
USA 
USA 
USA 
USA 
AUSTRA 
USA 
USA 
USA 
USA 
USA 
USA 


COMP ANY~8 


NAME 


PETERSON MERRILL A 
EDWARDS JON L 
CAYLOR LARRY W 
BLACK DAVID T 
HAMAN VINCE J 
WOMBACHER ERNEST J 
ALLAN WILLIAM D 
GUISINGER ERIC L 
LUITHLE WILLIARD H 
DUNCAN JAMES J 
BENJAMIN ROBERT A 
DAVY CHRIS 

DAVY CHRISTOPHER 
FELDMAN DAN 
ROUSSEAU ALLEN F 
HARMAN LAWRENCE K 
JESSEN TIM D 

LACY LEROY P 
DREILING CHERYL B 
JONES DANNY A 

LYNN DEAN E 


TITLE 
STAFF ENGINEER 


DATA PROCESSING MANAGER 
SYSTEMS ANALYST 
DIRECTOR DP 

CLERK OF DISTRICT COURT 
INFO SERVICES MANAGER 
PROGRAMMER/ANALYST SR 
COMPUTER OPS SUPV 
MANAGER CEM SALES 

SR SYSTEMS PROGRAMMER 
MANAGER 

PRODUCT MANAGER 


VP PRODUCT DEV 
GROUP LEADER 
COMPUTER SCIENTIST 
COMPUTER SCIENTIST 
COMPUTER SCIENTIST 
COMPUTER PROGRAMMER 
COMPUTER SCIENTIST 


LEIGHT BETSY (CANCELED DIRECTOR 


FLYNN DOUGLAS ¢ 
HANEWAL SANDRA S 
EATON JOHN 

GATES BILL 

MOIRAO DAVID E 
GORFINKEL HARTIN 
ARMSTRONG JACK C 
EXCOFFON MARGOT ¥ 
LARSON TERRY 

HAUS JOHN A 
JOHNSTON FRANK H 
KROESEN JACOBUS A 
VAN BUITENEN PETER 
_ ANKERS, JR ALFRED H 
' TZETT CRAIG N 
BOYER CONNIE Y 
BROWN DALE A 
DAILEY JOSEPH D 
THORNTON WILLIAM L 
GCHI YOSHIAKI 
ANDERSON GARY D 
CLARK KIM 
GILCHRIST DON 
SINHA DEEPAK 
SNELLINGS FRANK W 
WALESKT JR WALTER L 
GROSSCUP LORIN 
HUXHOLD PHIL W 


D P MANAGER 

SYSTEMS MANAGER 

DIR COMPUTER SERVICES 
DATA PROCESSING HGR 
PROGRAMMING HANAGER 
PARTNER 

PARTNER 

PROJECT LEADER 
PROJECT LEADER 
SYSTEMS ANALYST 
DIRECTOR DATA PROCESS 
MANAGER 0 & A 
SYSTEMS DEDMAN 
MANAGER DATA PROCESSING 
DIRECTOR TECHNOLOGY 
PROGRAMMER /ANALYST 
DIR OF INST RESEARCH 
MANAGER DATA PROCESSING 
PROGRAMMER/ANALYST 
EDP MANAGER 

ASSOC PROF OF BIOSTAT 


PROGRANHER 

PROJECTS DEV MANAGER 
DIR INFO SYSTERS 
PROGRAMHER 

DP MANAGER 


CLEMENTSON GERHARDT C DIR OF ACAD COHP CNTR 


GENTRY THOMAS L 


MER ENG’G COMPUTER CTR 


COMPANY 


JEFFERSON CHEMICAL 
JENNISON ASSOCIATES 
JOHANSON DIELECTRICS 
JOHN HENRY COMPANY 
JOHNSON COUNTY 

JOHNSON COUNTY IOWA 
KAISER FOUNDATION 
KAISER FOUNDATION 
KAISER FOUNDATION 
KAPPA SYSTEMS INC 
KEYDATA CORP 

KEYDATA CORP 

KEYDATA CORP 

KEYDATA CORP 

KEYDATA CORP 

LAWRENCE LIVERMORE LAB 
LAWRENCE LIVERMORE LAB 
LAWRENCE LIVERMORE LAB 


LAWRENCE LIVERMORE LABOR 
LAWRENCE LIVERMORE LABOR 
LAWRENCE LIVERMORE LABOR 


LEIGHT AND ASSOCIATES 
LEXINGTON HERALD LEAD 


ADDRESS 


P 0 BOX 847 

278 PARK 

2240 SCREENLAND DRIVE 
PD BOX 17099 

P 0 BOX 2540 

400 S CLINTON STREET 
2005 FRANKLIN ST 
2005 FRANKLIN ST 
2005 FRANKLIN 

{409 POTTER DR 

1400 WILSON BLVD 
{400 WILSON BLVD 
1400 WILSON BLVD 

108 WATER ST 

408 WATER ST 

P 0 BOX 808 HC L-389 
P 0 BOX 908 L-414 

P 0 BOX 808 MC L-389 
P 0 BOX 808 

P 0 BOX 808 

PO BOX 908 

44200 SHOLES COURT 
239 WEST SHORT ST 


LIBERTY COMMUNICATIONS INC 2225 COBURG ROAD 


LONDON GRAD SCH OF BUS 
LONGS DRUG STORES, INC 
LONGS DRUG STORES, INC 


LOS ALTON RESEARCH CENTER 
LOS ALTOS RESEARCH CENTER 


LYNES UNITED SERVICES 
LYNES UNITED SERVICES 
M.H. GOLDEN CO 

MACON TELEGRAPH PUB CO 
MAKRO INTL 

MAKRO INTL 

MARITIME TERMINALS 
MARTIN MARIETTA 

HARY WASHINGTON CLE 
MARY WASHINGTON CLG 
MASTERCRAFT IND 
MASTERCRAFT IND 


MATSUSHITA ELEC INDUST CO 


MC MASTER UNIVERSITY 
HC MASTER UNIVERSITY 
MC MASTER UNIVERSITY 
MC MASTER UNIVERSITY 
MEDIA GENERAL INC 
MEDIA GENERAL INC 
MERCHANDISING METHODS 
MERCHANDISING RETHODS 
METROPOLITAN ST COLLEGE 
MICROWAVE ASSOCIATES 


REGENT’S PARK 

{44 NORTH CIVIC DR 

{44 NORTH CIVIC DR 

339 S SAN ANTONIO ROAD 
339 S SAN ANTONIO ROAD 
309 2ND AVE SW 

309 eND AVE SW 

123 CAMINO DE LA REINA 
P 0 BOX 4167 

CHURCHILL LAAN if 
CHURCHILL LAAN if 

7737 HAMPTON BLVD 

300 EAST JOPPA RD 

P 0 BOX 1084 CLE STAT 
PO BOX {084 CLG STAT 
4881 IRONTON ST 

4881 IRONTON ST 

$2 MATSUSHITA HACHI 
1200 HAIN ST WEST 

4200 RAIN STREET WEST 
1200 MAIN ST WEST 

4200 MAIN ST W 

304 & GRACE ST 

304 E GRACE ST 

274 BRANNAN STREET 

274 BRANNAN STREET 
4006 41TH STREET 

SOUTH AVE 


ATTENDEE BY COMPANY 


CITY STATE ZIP COUNTRY 


PORT NECHES 1X 7765i USA 
NEW YORK NY 40017 USA 
BURBANK CA 91505 USA 
LANSING HI 48901 USA 
IGWA CITY 1A 52240 USA 
TOWA CITY TA 52240 USA 
DENVER CO 80205 USA 
DENVER CO 80205 USA 
DENVER CO 80205 USA 
COLORADO SPRI CO 80909 USA 
ARLINGTON VA 22209 SA 
ARLINGTON VA 22209 USA 
ARLINGTON VA 22209 USA 
WATERTOWN HA 02172 USA 
WATERTOWN MA 02172 USA 
LIVERNORE CA 94550 USA 
LIVERMORE CA 74550 USA 
LIVERMORE CA 94550 USA 
LIVERMORE CA 94550 USA 
LIVERMORE CA 94550 USA 
LIVERMORE CA 94550 USA 
LOS ALTOSHILL CA 94022 USA 
LEXINGTON KY 40507 USA 
EUGENE OR 97401 USA 
LONDON NWL4SA ENGLAN 
WALNUT CREEK CA 94596 USA 
WALNUT CREEK CA 94596 USA 
LOS ALTOS CA 94022 USA 
LOS ALTOS CA 94022 USA 
CALGARY AL TePOCS CANADA 
CALLARY AL T2POCS CANADA 
SAN DIEGO CA 92108 USA 
MACON GA 31208 USA 
3525 GUUTRECH NETHER 
352F GUUTRECH NETHER 
NORFOLK VA 23505 USA 
BALTIMORE MD 21204 USA 
FREDERICKSBUR VA 22401 USA 
FREDERICKSBUR VA 22404 USA 
DENVER CO 80239 USA 
DENVER CO 80239 USA 
MORIGUCHI-SHI 05 JAPAN 
HAMILTON ON L8S4J9 CANADA 
HAMILTON ON L8S4J9 CANADA 
HAMILTON ON L8S4J9 CANADA 
HAMILTON ON L8S4J9 CANADA 
RICHMOND VA 23219 USA 
RICHAOND VA 23219 USA 
SAN FRANCISCO CA 94107 USA 
SAN FRANCISCO CA 94187 USA 
DENVER CO 80204 USA 
BURLINGTON HA 01883 USA 


COMP ANY-9 


NAME TITLE 
SMITH TERRY 8B 
HC INNIS, JR. A HARVI 
DEBOK LOWELL W PROGRANMER/ANALYST 


OLSEN MARY ANN(CANCEL PROGRAMMER 
DUNCOMBE BRIAN C 
KWAVNICK MYER 


WAGNER DAVID L MANAGER DATA PROCESSING 


DINAN DENNIS # 

ENTIS GLENN PROGRAMMER ANALYST T 
MALUS JOSEPH T 

TETI FRANK A SYSTEM ANALYST 
KNIGHT JR WILLIAM J MANAGER INFORMATION 
CHASE LARRY ¥ SUPV SYS & PROGH 
MAGNUS ANN SUPV COMPUTER OPER 


STAMBAUGH JAN R 
LAVIOLA ANTHONY 
REITHNER JR ROBERT # 
RUSSELL KENT A 

PRICE RICHARD J 
RICKARD € ALLEN 


DIRECTOR DP 

SYSTEMS MANAGER 

MANAGER 

PRESIDENT 

HGR TECH SUPPORT 

HGR SYSTEMS DEVELOPMENT 


ROWE THOMAS C V P SYSTEMS NATIONWIDE FINANCE 
SULLIVAN DENNIS J MGR D P OPERATIONS NATIONWIDE FINANCE 
EDWARDS ROBERT Hi SPEC ASST FOR DP NATL CONF ST LEGISLATURES 
JEWEL MARTIN D MGR COMPUTER SERVICES NATL SCI DATA CENTER 
LIENARD JAMES B PROGRAMMER NATL SCI DATA CENTER 
HARRIS DAVID W HANAGER NBS FINANCIAL SERVICES 
CURBELO RALPH COST ANALYST NEW YORK TELEPHONE CO 
KILLCOMMONS PETER F GENERAL COST SUPY NEW YORK TELEPHONE CO 
BROWN D DAVID PRESIDENT NICE CORPORATION 

JEANS KENNETH E ASST HGR OF DATA PROC = © NOOTER CORP 

ROGERS THOMAS D ASSISTANT DIRECTOR NORFOLK STATE COLLEGE 
HC CLAIN HALCOLH E © MANAGER DATA PROCESSING NORTH IDAHO COLLEGE 
LULICH LEO J PROGRAMMER NORTHERN SPECIALTY 
MILLER LEROY ¥ D P HANAGER NORTHERN SPECIALTY SALES 
RODGER JOHN D NORTHERN TELECCH 
WHIDDON ROY L SPECIALIST SOFTWARE NORTHERN TELECOM LTD 
POLO FRANK SYSTEMS SPECIALIST NORTHROP CORP 

KROPP MICHAEL E SYSTEMS PROGRAMMER NORWCH-EATON PHARK 
SPORKEN HEIN P NOVA AUTOKATION CONS 
SHROADS, JR JANES C DIRECTOR COMP OPER NPD REASEARCH, INC 
BISHOP LARRY DIRECTOR SYSTEMS DEVELOP NPD RESEARCH, INC 
WEBER WILLIAM SYSTEHS ANALYST NPD RESEARCH, INC 
HOLMAN JAMES R HEAD STATISTICS LAB GHIO AGRIC R&D CENTER 
HUNTER JOHN C SYSTEMS SUPERVISOR OKANAGAN HELICOPTERS 
NILLARD MICHAEL J © PROGRAMMING SUPERVISOR  GKANAGAN HELICOPTERS 
CRAWFORD JEFFREY D PRESIDENT OMEGA SYSTEMS, INC. 
RICKS DAVID L PROGRAMMER ANALYST PACIFIC AUTUAL 

VILLA JR CHARLES J PRESIDENT PANTECHNIC 

WRIGHT DALE PANTECHNIC 

BUTLER STEPHEN if DIRECTOR DATA PROCESSING PARADISE VALLEY HOSPITAL 
"ARKER KENNETH DIRECTOR & DP PARISIAN INC 

SCHLOSSER JR ROBERT J COMPUTER SCIENTIST PEPCO 


COMPANY 


CHIEF OF DATA PROCESSING MILO BEAUTY SUPPLY CO 


MINI/MICRO SYSTEMS INC 
MITCHELL BROS TRUCK 
MITCHELL BROS TRUCK 
MOHAWK COLLEGE 


ADDRESS 


4670 ALLEN ROAD 

S3i5 N SHARTEL AVE 
3844 N COL BLVD 

3841 N COLUMBIA BLVD 
PO BOX 2034 


MONTREAL CHILDRENS HOSPITA 2300 TUPPER 


MOORE & CO 


SENIOR PROGRAMMER ANALYS HORGAN GUARANTY TRUST 


MORGAN GUARANTY TRUST 


SENIOR PROGRAMMER ANALYS MORGAN GUARANTY TRUST 


MORGAN GUARANTY TRUST 
MULTIVEST INC 
MULTNOMAH COUNTY ESD 
KULTNOMAH COUNTY ESD 
MULTNOMAH COUNTY ESD 
N Y TELEPHONE CO 
N.E.R.A, 

NATIONAL COMPUTER CORP 
NATIONWIDE FINANCE 
NATIONWIDE FINANCE 


500 E SPEER BLVD 

23 WALL STREET 

23 WALL STREET 

37 WALL STREET 

23 WALL STREET 

6452 N FEDERAL HWY 
20 SE 102 

é20 SE i02 

220 SE 102 

575 PEARL ST 

80 BROAD STREET 

5000 34TH ST 

700 OFFICE PARKWAY 
700 OFFICE PARKWAY 
700 OFFICE PARKWAY 
700 OFFICE PARKWAY 
444 N CAPITOL ST NW 
1130 E MC DOWELL RD 
1130 & MC DOWELL RD 
508 W WILSON BDG RD 
1095 AVE OF THE AMERICAS 
1095 AVE OF THE AMERICAS 
4357 AIRPORT PARK PLAZA 
P 0 BOX 45 

2401 CORPREW AVE 
10069 W GARDEN AVENUE 
6655 N BALTIMORE 
6635 N BALTIMORE 
8200 DIXIE RD 

33 CITY CENTRE DRIVE 
2504 WEST 120 STREET 
135-17 EATON AVENUE 
30 NEDEREIND 

iS VERBENA AVENUE 

15 VERBENA AVENUE 

{5 VERBENA AVENUE 


4391 AGAR DRIVE 

4391 AGAR DRIVE 

5728 SO ROCKWELL ST 

700 NEWPORT CENTER DRIVE 
5805 OCEAN VIEW DR 

S805 OCEAN VIEW DR 

2406 E 4TH STREET 

{104 26TH STREET N 

4980 PENNA AVE 


ATTENDEE BY COMPANY 


CITY STATE ZIP COUNTRY 


STOW 


QH 44224 USA 


OKLAROMA CITY GK 73118 USA 


PORTLAND 
PORTLAND 
HAMILTON 
MONTREAL 
DENVER 

NEW YORK 
NEW YORK 
NEW YORK 
NEW YORK 


OR 97247 USA 
OR 97217 USA 
ON LBNST2 CANADA 
QU HIHIP3 CANADA 
CO 80283 USA 
NY 10015 USA 
NY 40015 USA 
RY £0015 USA 
NY £0045 USA 


FT LAUDERDALE FL 33308 USA 


PORTLAND 
PORTLAND 
PORTLAND 
NEW YORK 
NEW YORK 
METAIRIE 


CREVE COEUR 
CREVE COEUR 
CREVE COEUR 
CREVE COEUR 
WASHINGTON 


PHOENIX 
PHOENIX 
COLUMBUS 
NEW YORK 
NEW YORK 
ODGEN 

oT LOUIS 
NORFOLK 


OR 97216 USA 
OR 97216 USA 
OR 97216 USA 
NY 10038 USA 
NY 10004 USA 
LA 70004 USA 
MO 63444 USA 
HO 6341 USA 
MS 63144 USA 
MO 63141 USA 
DC 2000% USA 
AZ 85006 USA 
AZ 85006 USA 
OH 43285 SA 
NY 10036 USA 
NY 10036 USA 
UT 84403 USA 
HO 63166 USA 
VA 25504 USA 


COEUR D’ ALEN ID 83814 USA 


PORTLAND 
PORTLAND 
BRAMPTON 


NISSISSAUGA 
HAWTHORNE 


NORWICH 


NIEUWEGEIN 
FLORAL PARK 
FLORAL PARK 
FLORAL PARK 


WOOSTER 


VANCOUVER 
VANCOUVER 


CHICAGO 


OR 97203 USA 
OR 97203 USA 
ON LaV2H6 CANADA 
ON LSB2NS CANADA 
CA 90250 USA 
NY 43815 USA 
NETHER 
NY {1601 USA 
NY {1604 USA 
NY 141001 USA 
CH 44691 USA 
BC V7BiaS CANADA 
BC V7BiAS CANADA 
TL 68632 USA 


NEWPORT BEACH CA 92660 USA 


CAKLAND 
GAKLAND 


CA 94618 USA 
CA 94618 USA 


NATIGNAL CITY CA 92050 USA 


BIRMINGHAM 


AL 35234 USA 


WASHINGTON DC 28068 USA 


COMP ANY-18 


NAME 


ARNOLD PAT 
CURTIS LINDA 
DURHAK PAUL H 
NEMETH LOUIS E 
GARDINER JAMES A 
METZNER BERNIE 


STOCKDALE WALLACE L 


HUXHAM BASIL C 

HC CREA ROBERT B 
SMITH RAYHOND E 
ARCAYA PEDRO i 
TANKERSLEY JAMES J 
LUMB ARTHUR C 
KEYER DIANNE H 
VEENEMAN WILLIAM E 
COX W PHIL 

GODDHAN ROBERT A 
CARVALHO MARCOS A 
TICHAUER MARIO F W 
MOWER MONTE J 
SMITH BARRY 

FARIA JOHN 

BARKER DAVID A 
PACHALY FRED A 
DUMMER SHEILA 1 
FISCHER LEE 
CHATFIELD DENNIS C 
RASKUSSEN BENT 
WHITE RUSS 

WILSON ROBERT L 
KULVIHILL GARY 
MAHONEY LARRY 

ONEY JAKES B 
SOHNLE RONALD C 
SCOTT GEORGE B 
FRANSEN CRAIG § 


TITLE 


SYSTEM ENGINEER 
ANALYST/PROGRAHMER 
SYSTEMS ANALYST PROG 
DIRECTOR ENG COMP CTR 
KIS MANAGER 

OPERATIONS HGR 

DP MANAGER 

MANAGER DATA PROCESSING 
CHIEF FINANCIAL OFFICER 
DATA PROCESSING MANAGER 


GER 
SR SYSTEMS ANALYST 
CONSULTANT 
OPERATIONS COORDINATOR 
SYSTEMS ANALYST 
SYSTEMS ANALYST 
PRESIDENT 
SYSTEMS ANALYST 
ENGINEER 
SYSTEM MANAGER 


MGR COMPUTER SERVICES 
MANAGER SYSTEMS & PROG 
PROGRAMMER 


COMPANY 


PETRO CANADA 

PETRO CANADA 

PETRO CANADA INC 
PHILA WATER DEPT 
PILKINGTON BROS 
PILKINGTON GLASS LTD 
PORT OF CAKLAND 

PORT OF VANCOUVER 
PORT OF VANCOUVER 
POWERS REGULATOR 
PROCESASEG, SA 
PROCTER & GAMBLE 
PROCTER & GAMBLE CO 
PROCTER & GAMBLE CO 
PROCTER & GAMBLE CO 
PROCTOR & REDFERN 
PROF COMP SERV 
PROMON ENGENHARIA S A 
PROMON ENGENHARIA S A 
PROVO SCHOOL DISTRICT 
PRUDENTIAL INSURANCE 
PRUDENTIAL REINSURANCE 
PURITAN INSURANCE CO 
PURITAN INSURANCE CO 


MANAGER FINANCIAL SYSTEM QUME CORP 
MANAGER DATA PROCESSING QUME CORP 


SYSTEM MANAGER 
VICE PRESIDENT 
PRESIDENT 
SALES HGR 


SUPERVISOR SEATTLE COMP 
DATA PROCESSING MANAGER 
MGR COMPUTING SERVICES 
MANAGER 

SYSTEM ANALYST 


FREDRICKSON GUNNARD A PROJECT LEADER 


SNEED JAMES E 


HC CORMICK DOUGLAS B 


WRIGHT STEVE T 
GREEN ANNABELLE H 
GREEN ROBERT # 
LEWIS KERMON 
BEHELER ANN F 
GEYER SANFORD A 
GWALTHNEY DAVID L 
FRYER WILLIAN R 
KIRK TIM L 
PHILLIPS TERRY 
BRUCE CLIFF 

GOT TERRENCE 
NORRIS BOB 


CORPORATE HGR D P 
MER INFORMATION SYS 
MANAGER HOME OFFICE 
SECRETARY/TREASURER 
PRESIDENT 

V P DATA PROCESSING 
PROJECTS MANAGER 
SYSTEM MANAGER 
DIRECTOR-CCIS 
PRESIDENT 

DIRECTOR INFO SYSTEMS 
DEVELOPMENT MANAGER 
D P ASST MANAGER 

D P MANAGER 
PROGRAMMER ANALYST 


R J FRISBY 

R SHRIVER ASSOCIATES 
R SHRIVER ASSOCIATES 
R SHRIVER ASSOCIATES 
R SHRIVER ASSOCIATES 
R W BECK & ASSOCIATES 
RCH 


ADDRESS 


P 0 BOX 2844 

P 0 BOX 2844 

400 4 AVE SW 

1270 HSB 

G85 WARDEN AVE 

685 WARDEN AVE 

66 JACK LONDON 5Q 
4300 STEWART ST 

{300 STEWART ST 

RR #1 

TORRE LA PREVISORA 

P 0 BOX S99 

7162 READING RD 

6105 CENTER HILL RD 
6105 CENTER HILL RD 
7S EGLINTON AVE E 
282i E 28TH STREET 
NOVE DE JULHO 4939 
NOVE DE JULRO 4939 
280 WEST 800 NORTH 
243 WASHINGTON ST 

2i3 WASHINGTON ST 
iSi5 SUMMER ST 

i545 SUMMER ST 

2323 INDUSTRIAL PARKUAY 
2323 INDUSTRIAL PARKWAY 
i500 CHASE 

{20 LITTLETON ROAD 
420 LITTLETON ROAD 
{20 LITTLETON ROAD 
4530 CHESTNUT SUITE 744 
200 TOWER BUILDING 
ONE MARKET PLAZA 3940 


REGIONAL ECONOMIC EXPANSIO 601 SPADINA CRESCENT 


REICHHOLA CHEN 
REICHHOLD CHEM 
RELIANCE ELECTRIC 
RELIANCE ELECTRIC 
REPUBLIC GEOTHERMAL 
REPUBLIC MORTGAGE INS 
ROBELLE CONSULTING LTD 
ROBELLE CONSULTING LTD 
ROBERT JAMES CO 
ROCKWELL INTL-COLLINS 
ROLM CORP 

RUTGERS UNIVERSITY 
§.B.D.P, 

SACRED HEART GEN HOSP 
SACRED HEART GEN HOSP 
SAN JOSE MERCURY-NEWS 
SAN JOSE MERCURY-NEWS 
SAN JOSE MERCURY-NEWS 


2349 TAYLOR WAY 

2340 TAYLOR 

i50 CANTERBURY DR 

P 0 BOX 5065 STATION B 
41823 E SLAUSON #1 

P 0 BOX 2514 

$130-5421 10TH AVENUE 
#130-5421 40TH AVENUE 


1200 N ALMA RD 

4960 OLD IRONSIDES DR 
344 N FIFTH STREET 
4208 AIRPORT ROAD 

P 0 BOX 10905 

PO 10905 

750 RIDDER PARK DR 
750 RIDDER PARK DR 
750 RIDDER PARK DR 


ATTENDEE BY COKPANY 


CITY STATE ZIP COUNTRY 


CALGARY AL TeP2H7 CANADA 
CALGARY AL TeP2H7 CANADA 
CALGARY AL T2PeH7 CANADA 
PHILADELPHIA PA 19407 USA 
SCARBOROUGH © ON MiL3Z8 CANADA 
TORGNTO ON MiL3X7 CANADA 
OAKLAND CA 94606 USA 
VANCOUVER BC VSLAXS CANADA 
VANCOUVER BC V5L4X5 CANADA 
BEETON ON LOGLAQ CANADA 
PISO SABANA 6 VENEZU 
CINCINNATI  QH 45201 USA 
CINCINNATI OH 45208 USA 
CINCINNATI OH 45220 USA 
CINCINNATI OH 45220 USA 
TORONTO ON M4PiH3 CANADA 
LONG BEACH CA 92648 USA 
SAD PAULO SP 04407 BRAZIL 
SAO PAULO SP 041407 BRAZIL 
PROVO UT 84601 USA 
NEWARK NJ 07401 USA 
NEWARK NJ 07104 USA 
STAMFORD CT 06905 USA 
STAMFORD CT 96905 USA 
HAYWARD CA 94545 USA 
HAYWARD CA 94545 USA 
ELK GROVE TL 60007 USA 
PARSIPPANY NJ 07054 USA 
PARSIPPANY NJ 07054 USA 
PARSITPANY NJ 07054 USA 
PHILADELPHIA PA 49102 USA 
SEATTLE WA 98101 USA 
SAN FRANCISCO CA 94105 USA 
SASKATOON SA S7K3GB CANADA 
TACCHA WA 98401 USA 
TACOMA WA 98404 USA 
ATHENS EA USA 
GREENVILLE SC 29606 USA 
SANTA FE SPRI CA 90670 USA 
WINSTON SALEM NC 27102 USA 


DELTA 


DELTA 

BIRMINGHAM = AL 
RICHARDSON =: TX 75081 
SANTA CLARA CA 95650 
CAMDEN NJ 08102 
CINCINNATI OH 45226 
EUGENE OR 97404 
EUGENE OR 97401 
SAN JOSE CA 95190 
SAN JOSE CA 95190 
SAN JOSE CA 95190 


BC VAN3T9 CANADA 
BC V4N3T9 CANADA 


USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 


COMPANY~4i 


RAHE 


MARTIN STEVE T 
JAMES ROBERT # 
FLOWERS CURTIS J 
CARR CHARLES E 
KLETT DONALD S 
FINNEY BILLIANNA Hi 
VICHL KEN 

ST PIERRE JEAN 
ADAKS BOB 

KING NEIL R 

HC LECD PAT 
SHELLEY NANCY 
WARP CRAIC 

SHOUP BRYAN 
SEWELL DAVID 
DEMEVSY JIN 
SMART JOHN E 
SPIELER CHARLES W 
SARBAUGH JAY C 
HOUY DAVID J 
ADAKS KEARNEY A 
BERNKEN H PAUL 
KENDALL JOHN 
BAKST LAWRENCE E 
BANSAL A K 


TITLE 


SYSTEMS ANALYST 
ANALYST/PROGRAMHER 
DP ANALYST II 

MAN ANALYST PROG II 


DIRECTOR UNIVERSITY LAB 


PROGRAMMER 


DP MANAGER EXD 
SYSTEMS EDP MANAGER 
PROGRAMMING SUPV 
PROGRAMMER 

SYSTEMS PROGRAMMER 


DATA PROCESSING HER 


COMPANY 


SANDIA LABORATORIES 
SANDIA LABS 
SANGAMON STATE UNIV 


SANGAHON STATE UNIVERSITY 
SANGAMON STATE UNIVERSITY 


SANTABARBARA RESEARCH 


SATELLITE COMPUTING, INC 


SCOTT PAPER LTD 
SCOTT PAPER LTD 
SCOTT PAPER LTD 
SCOTT PAPER LTD 
SCOTT PAPER LTD 
SHUGART ASS 

SIT DYNA-DRILL 


DIRECTOR OF DATA PROCESS SII SERVCO 


VICE PRESIDENT 
DIRECTOR HIS 

VICE PRESIDENT 
FINANCIAL SYSTEMS HER 
SR PROGRAMMER ANALYST 
SUPVR DATA PROCESSING 
SYSTEMS PROGRAMMER 
SENIOR CONSULTANT 


THOMPSON JR CHARLES H INFORMATION MGMT CHF 


BRAUN GUENTHER K 
PENNALA ERIC # 
HEINEN TERRY H 


EDWARDS CONSTANCE E 


RODRIGUEZ DAN R 


DIRECTOR DATA PROC 
MANAGER PROG & OPS 
E D P MANAGER 
MANAGER COMPUTER CTR 
PROJECT LDR SUPPLY 


BIVENS FREDERICK (CANC)DATA SPECIALIST 


JEFFRIES WILLIAM F 
SRELSER LINDA C 
STUMP DALE K 

ALEXY MICHAEL J 


COORDINATOR ICS 
ASST GENERAL HER 
DATA PROCESSING HGR 
DATA SYSTEMS STAFF 


HOLLING ERNEST(CANCEL)DIRECTOR-DATA SYSTEMS 


MORRISON JAMES C 
BROOKS ROY 
BOWNES GORDON 
BRICKER HARLEY G 


MANAGER D P 


SYSTEMS ANALYST 
SUPT MATERIALS 


SILTON DATA INC 
SILTON DATA INC 
SIACO 


SMALL BUSINESS DATA PROC 


SMITH INTERNATIONAL 
SMITH KLINE INST 
SMITHS INDUSTRIES 

SO MISSIONARY COLLEGE 
SOFTWARE SYSTENS TECH 
SOHIO 

SPACE & MSL SYS DIV 
SPRECKELS SUGAR DIV 
SPRECKELS SUGAR DIV 
ST CLOUD HOSPITAL 

ST FRANCIS XAVIER UNIV 
STANDARD OIL CO 
STANDARD OIL COMPANY 
STARK COUNTY DEPT ED 


STATE CONTROLLERS OFFICE 
STATE CONTROLLERS OFFICE 


STORER BROADCASTING 
STORER BROADCASTING 
SUN HYDRAULICS CORP 


SYNCRUDE CANADA LIMITED 


SYNCRUDE CANADA LTD 
SYNCRUDE CANADA LTD 


AUSTIN DONALD (CANCEL)MGR SYSTEMS & OPERATIONS SYRACUSE BOARD OF EDUC 


FOSTER RICHARD H 
BRYSON GARY J 
CONNOR JACK 
ROSENBERG IVAN H 
DUMAS ROBERT J 
FRASER TOM 
MEYERS LAWRENCE 
WICKHAM GAIL 0 
STEIN SALLYSUE 
STOVER DAVID W 


MANAGER SYSTEM S/W 
CONSULTANT 

SR CONSULTANT 
GENERAL PARTNER 
MARKETING SUPPORT 


DIRECTOR OF MARKETING 


HER MARKETING SERVICES 


PARTNER 
DIR OF INFO SERVICES 


SYSTEM DEVELOPMENT CORP 


SYSTEM HOUSE 

SYSTEMS & COMP TECH 
SYSTEMS DESIGN ASSOC 
SYSTEMS RESEARCH INC 
SYSTEMS RESEARCH INC 
SYSTEMS RESEARCH INC 
SYSTEMS RESEARCH INC 
T.0.A.D, 

TELEPHONE EMPLOYEES CO 


ADDRESS 


DIVISION 2627 

P 0 BOX S800 
SHEPHERD ROAD 
SHEPHERD ROAD 
SHEPHERD ROAD 

75 COROKAR DRIVE 
PO BOX 2045 

P O BOX 760 

P 0 BOX 760 

P 0 BOX 768 

P 0 BOX 760 

P 0 BOX 760 

435 OAKMEAD PARKWAY 
{774 DEERE AVENUE 
PO BOX 880 

2407 E 38TH STREET 
2407 E 38TH STREET 
21004 CABOT BLVD 
4208 AIRPORT ROAD 
4343 VON KARMAN AVE 
880 W MAUDE AVENUE 
P 0 BOX S389 


39 BROADWAY SeND FL 


2B05 MAPLE AVENUE 
50 CALIFORNIA ST 

50 CALIFORNIA ST 
1406 6TH AVENUE NO 
PO BOX 67 ST.F.X.U. 
£090 GUILDHALL BLDG 
{01 W PROSPECT AVENUE 
7800 COLUMBUS RD 
504 E MUSSER 

504 E MUSSER 

14177 KANE CONCOURSE 
1177 KANE CONCOURSE 
1817 57TH STREET 
10030 107TH STREET 


£0030 107TH ST 7TH ST PLAZA EDMONTON 


P 0 BAG 4009 

409 W GENESEE ST 
e500 COLORADO AVENUE 
560 ROCHESTER 

7 NS POINT RD 

PO BOX 1144 

2400 SCIENCE PARKWAY 
2400 SCIENCE PARKWAY 
2400 SCIENCE PARKWAY 
2408 SCIENCE PARKWAY 
{9855 GIESENDORFER RD 
639 S NEW HAMPSHIRE 


ATTENDEE BY COMPANY 


CITY STATE ZIP COUNTRY 


ALBUQUERQUE NM 87185 USA 
ALBUQUERQUE NM 87165 USA 
SPRINGFIELD IL 62708 USA 
SPRINGFIELD IL 62768 USA 
SPRINGFIELD IL 62708 USA 
GOLETA CA 935017 USA 
NORFOLK VA 235501 USA 
CRABTREE PQ CANADA 
NEW WESTHINST BC CANADA 
NEW WESTMINST BC CANADA 
NEW WESTHINST BC CANADA 
NEW WESTMINST BC CANADA 
SUNNYVALE CA 94086 USA 
IRVINE CA 92713 USA 
GARDENA CA 90247 USA 
VERNON CA 90858 USA 
VERNON CA 90058 USA 
HAYWARD CA 94545 USA 
CINCINNATI OH 45226 USA 
NEWPORT BEACH CA 92660 USA 
SUNNYVALE CA 94086 USA 
CLEARWATER = FL USA 
COLLEGEDALE TN 3731S USA 
NEW YORK HY 10086 USA 
CLEVELAND OH 44445 USA 
MANHATTAN BEA CA 90266 USA 
SAN FRANCISCO CA 944i USA 
SAN FRANCISCO CA 94441 USA 
ST CLOUD HN S630i USA 
ANTIGONISH NS B2G&CO CANADA 
CLEVELAND OH 44415 USA 
CLEVELAND OH 4441S USA 
LOUISVILLE GH 44641 USA 
CARSON CITY NV 89704 USA 
CARSON CITY NV 89704 USA 
BAY HARBOR IS FL 33454 USA 
BAY HARBOR IS FL 33154 USA 
SARASOTA FL 33580 USA 


EDMONTON 


FT HC MURRAY 
SYRACUSE NY 13202 
SANTA MONICA CA 90406 
OTTAWA 
WEST CHESTER PA {9380 


SAN LUIS OBIS CA 93406 
OKEMOS MI 48864 
CKEMOS MI 48864 
OKEMOS MI 48864 
OKENOS HI 48864 
COLFAX CA 95713 


LOS ANGELES CA 90005 


AL TSJ3ES CANADA 
AL TSJ3ES CANADA 
AL T9H2Li CANADA 


USA 
USA 


ON KiBSBB CANADA 


USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 


COMPANY-{2 


NAHE 


GEER ROSS E 

WRIGHT JAKES C 
MURPHY JR ROBERT 
MILLER WILLIAM J 
PRICE ROGER 
THORSON RON 
ELLIOTT HARRY A 
TEARE ROBERT F 
AUSLANDER RICHARD C 
BOSCO SUSAN Ki 
KOMAR JANES 

DAK JACK A 

LANGE JOHN Hi 
LIGHTHEART TED Hf 
FLOYD TERRY H 
NORTH CARL H 
TROWBRIDGE VERN H 
NEWMAN ALAN T 
SILVER GAYE L 
JONES MORGAN 

MC GRATH JOSEPH 
VILLARREAL RANON V 
KING STEPHEN E 
CLEMENT RUBY J 
WILKINSON JIM L 
JARVIS RAY D 
CULPEPPER BRITTON B 
EDWARDS BENJAMIN E 
HC CLURE HERSCHEL D 
GOOLSBY MONTY P 
HOCK MADISON 0 
LUISI WILLIAK F 
NICHOLS MARTIN D 
HAYS GARRY R 

NAGEL PATRICK # 
NONAHAKER LAURA S 
FREDRICKSON STEVE 
CLEVELAND WALTER 
GRACE JAYNIA 

ADDIS JOHN 

GEWECKE JOHN W 
MEYERS BARRY 

NOLAN VINCENT 
CHITWODD RICK L 
TOWNSEND RICHARD 
REGO F ALFREDO 
SISOIS HIKES N 
TRUE JOHN F 
LINDSTROM EDWARD R 
ARANDA JORGE A 
GALLARDO PEDRO A 
ALVAREZ HANUEL A 


TITLE COMPANY 

TEXAS HUN POWER AGENCY 
TEXAS HUN POWER AGENCY 
TEXAS MUNICIPAL POWER 
THE BOVAIRD SUPPLY CO 
THE BOVAIRD SUPPLY CO 
THE BOVAIRD SUPPLY CO 
THE CANADA STARCH CO 
THE CLAREMONT COLLEGES 


DIRECOTR OF SYS ENGR 
ELECTRICAL ENGINEER 
DIRECTOR ADMINISTRATION 
HER CORP SYS PLANNING 
SYSTEMS ANALYST 

DATA PROCESSING HGR 
MANAGER HIS DEPARTMENT 
ASST DIR BIBL SERV 

DB DC TECH SPECIALIST | THE GAP STORES INC 
PROJECT MANAGER THE GAP STORES INC 
DIRECTOR DATA PROCESSING THE WH W WILSON CO. 


PRINCIPAL/OUNER THE PALO ALTO GROUP 
PROGRAMMER ANALYST THE TORG COMPANY 
ANALYST/PROGRAMMER THE WILLAMETTE VALLEY CO 


THERHON 
THOMAS NELSON COW COL 
TIDEWATER COMM COLL 


ACCNT SYSTEMS ANALYST 
DIRECTOR COMPUTER CTR 
MGR DATA PROCESSING 


INFO SERVICES HGR TOWER HANAGEMENT 

SYSTEMS ANALYST TRW COLORADO ELECT 
TYMDATA CORP 
TYADATA CORP 
TYRWARE CORP 

PROGRAHMER/ANALYST USAF 

DIRECTOR OF DP UMPQUA COMM COLLEGE 

GENERAL PARTNER UMPQUA DATA FACTORY 

PROGRAMMER UMPQUA DATA FACTORY 


SYSTEMS ANALYST UNION CAMP CORP 
ASST MGR DATA PROCESSING UNION CAMP CORP 
HGR SYSTEMS DEPT UNION CAMP CORP 


SYSTEMS MANAGER UNION CAMP CORP 
MGR INFO SYS BAG DIV UNION CAMP CORP 
SOFTWARE ANALYST UNION CAMP CORP 
TECHNICAL ANALYST UNION CAMP CORP 
SR DATA COMMUNICATION UNION OIL CO 


UNION OIL COMPANY 
UNION OIL COMPANY 
UNITED COMPUTING SYS 
UNITED COMPUTING SYS 
UNITED COMPUTING SYS 


SYSTEMS PROGRAMMER 
PROGRAMMER /ANALYST 
DISTRICT SALES HGR 


MER CONSULTING SVCS UNITED COMPUTING SYS 
DISTRICT SALES HGR UNITED COMPUTING SYS 
NATIONAL SALES HGR UNITED COMPUTING SYS 


UNITED HC GILL CORP 


ASST V P INFO SYS UNITED PRESIDENTIAL LIFE 


PROGRAMMER/ANALYST UNITED PRESIDENTIAL LIFE 
PROFESSOR UNIV F MARRGQUIN 
DIRECTOR INFO SYSTEMS UNIV OF SANTA CLARA 

DIR COMPUTING SERVICE UNIV OF TENNESSEE 


DIRECTOR-AGRI DATA CT = —sUNIVERITY GF KENTUCKY 


SYSTENS ENGINEER UNIVERSIDAD BAJA CAL 
SYSTEM ENGINEER UNIVERSIDDO BAJA CAL 
COORDINATOR 


ADDRESS 


22e5 E RANDOL MILL RD 
2225 E RANDOL MILL RD 
600 ARLINGTON DOWNS 
823 S DETROIT 

823 S DETROIT 

823 § DETROIT 

{ PLACE DU COMMERCE 
HONNOLD LIBRARY 

900 CHERRY AVE 

900 CHERRY AVE 

950 UNIVERSITY AVENUE 
790 LUCERNE DRIVE 
5825 JASMINE STREET 
660 MC KINLGY ST 

{00 THERMON DR 

PO BOX 9407 

RT 135 

{779 TRIBUTE ROAD #H 
3450 N NEVADA AVE 

44 W JEFFERSON ST 

44 W JEFFERSON ST 

44 W JEFFERSON ST 

LOS ANGELES AIR FORCE STA 
P 0 BOX 967 

222 E il 

727 SE CASS 


P O BOX 570 

P 0 BOX 1825 

i600 VALLEY RD 

4600 VALLEY RD 

464 S BOYLSTON ST 

{35TH ST & NEW AVE 

461 BOYLSTON RM M327 
4544 POST OAK PL #146 
2525 WASHINGTON 

2525 WASHINGTON 

i904 AVE OF STARS #585 
{904 AVE OF STARS #585 
{994 AVE OF STARS #585 
2400 FAIRWOOD AVE 

217 SOUTHMAY BLVD E 

217 SOUTHWAY BLVD E 

6A AVE 0-28 ZONA 10 
BANNAN HALL 113 

6i5 MC CALLIE AVENUE 
S107 AG SCI CTR N 
OBREGON Y F 

OBREGON Y F C CALCOLO 


UNIVERSITY IDAMETROPOLITAN APDO POSTAL 55-503 


ATTENDEE BY COHPANY 


CITY STATE ZIP COUNTRY 


ARLINGTON TX 76041 
ARLINGTON TX 76044 
ARLINGTON TX 76044 
TULSA OK 74102 
TULSA OK 741682 
TULSA OK 7482 


USA 
USA 
USA 
USA 
USA 
USA 


NUNS? ISLAND QU H3E1A7 CANADA 


DARTMOUTH AT CA 94744 
SAN BRUNO CA 74066 
SAN BRUNO CA 94066 
BRONX NY 10452 
SUNNYVALE CA 94086 
RIVERSIDE CA 92504 
EUGENE OR 97402 
SAN MARCOS TX 78666 
HAMPTON VA 23670 
PORTSMOUTH == VA 23701 
SACRAMENTO © CA _-95815 
COLORADO SPRI CO 80907 
BROWNSVILLE 1X 78520 
BROWNSVILLE TX 78520 
BROWNSVILLE 1X 78520 
EL SEGUNDO A 
ROSEBURG OR 97476 
EUGENE OR 97404 
ROSEBURG OR 97470 
FRANKLIN VA 25851 
FRANKLIN VA 23651 
FRANKLIN VA 2385 
SAVANNAH GA 31402 
SAVANNAH GA 31402 
WAYNE NJ 07476 
WAYNE NJ 07470 
LOS ANGELES CA 98017 
LEMONT IL 60439 
LOS ANGELES CA 90617 
HOUSTON TX 77027 
KANSAS CITY NO 64408 
KANSAS CITY M0 64108 
LOS ANGELES CA 90067 
LOS ANGELES CA 90067 
LOS ANGELES CA 90067 
COLUMBUS OH 43207 
KOKOHO IN 46901 
KOKOHO IN 46904 
GUATEMALA 

SANTA CLARA CA 95053 
CHATTANOOGA IN 57402 
LEXINGTON KY 40506 
MEXICALI BAJA 

MEXICALI MAJA 

REXICO DF 13 


USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
USA 
GUATEN 
USA 
USA 
USA 
HEXICG 
HEXICO 
MEXICO 


COMPANY-i3 


ATTENDEE BY COHPANY 


NAME TITLE COMPANY ADDRESS CITY STATE ZIP COUNTRY 
SCHULER KURT J DIR / COMP SERVICES UNIVERSITY GF DALLAS IRVING TX 75864 USA 
CHRISTOPHERSON DIANE UNIVERSITY OF WISCONSIN RIVER FALLS WI 54822 USA 
NELSON MARLYS UNIVERSITY OF WISCONSIN RIVER FALLS WI 54022 USA 
PROCHNOW NEAL UNIVERSITY OF WISCONSIN RIVER FALLS WI 54022 USA 
PETERSON DON SYSTEMS PROGRAMMER US CIVIL SERV COMM 4685 LOG CABIN DR MACON GA 31210 USA 
WRIGHT NORMAN B EXAMINING SYSTEMS COORD US CIVIL SERVICE COMM 4685 LOG CABIN DR MACON GA 31286 USA 
SPAHN CARL P DIRECTOR ADSS US DEPT AGR-APHIS 6525 BELCREST RD #853 HYATTSVILLE MD 20782 USA 
TAYLOR PAUL ¥ COMPUTER SPECIALIST US DEPT AGRICULTURE 6525 BELCREST RD #853 HYATTSVILLE MD 20782 USA 
SPERLE GLENN H COMPUTER SPECIALIST US DEPT OF AGR-APHIS 6525 BELCREST RD #853 HYATTSVILLE HD 20782 USA 
SELLERS HARRY P ADM DP MANAGER VA WESTERN COM COL 3095 COLONIAL AVE ROANOKE VA 24815 USA 
CARLSON LEE A PROF HATH & COMP SCIENCE VALPARAISO UNIVERSITY ACADEMIC COMPUTER CENTER VALPARAISO IN 46383 USA 
HODSON DICK DP MANAGER VALTEC BOX 2200 SPRINGVILLE UT 84663 USA 
SIMONSEN J LAWRENCE COKPUTER SYSTEMS ENGR  VALTEK INC MOUNTAIN SPRINGS PRKWY SPRINGVILLE UT 84663 USA 
GILL RICK SYSTEMS ANALYST VANDERBILT UNIVERSITY S24 KIRKLAND HALL NASHVILLE TN 37235 USA 
DOLAN JR DOUGLAS C SPECIAL PROJECTS MGR VICTOR O SCHINNERER 5028 WISCONSIN AVE NW WASHINGTON DC 20046 USA 
BASSELLIER JEAN-PAUL DIRECTEUR INFORMATIQUE VILLE SAINT-LAURENT 777 BOUL LAURENTIEN SAINT-LAURENT QU H4M2M7 CANADA 
NEWELL RUSSELL L SYSTEMS ANALYST VOFM-DEARBORN 4901 EVERGREEN DEARBORN MI 48128 USA 
RADOFF IRVING SUPVR SYS/PROG VSI CORPORATION 8463 HIGUERA ST CULVER CITY CA 90230 USA 
HACKMAN LINFORD B © ADMIN SOFTWARE MGR VYDEC INC 9 VREELAND ROAD FLORHAM PARK NJ 07932 USA 
HEDA SHARAD MANAGER ADM SYS VYDEC INC 9 VREELAND ROAD FLORHAM PARK NJ USA 
POLAKOWSKI KEN GRP HGR SOFTWARE SUPPORT VYDEC INC 9 VREELAND RD _ FLORHAH PARK NJ USA 
WALLACE DARL L DIR EDUC COMP CTR WALLA WALLA COLLEGE COLLEGE PLACE WA 99324 USA 
SHUMATE D CRAIG MANAGER CS D WARREN & VAN PRAAG 1276 NORTH WARSON RD ST LOUIS M0 63132 USA 
AGRUSTI RAYHOND J WAYNE BOARD OF ED 50 NELLIS DRIVE WAYNE NJ 07470 USA 
OMI G KEVIN MANAGER WELLS FARGO BANK 420 MONTGOMERY ST SAN FRANCISCO CA 94444 USA 
RUSSELL BRIAN G PROGRAMMER /ANALYST WEST FRASER MILLS BOX 6000 QUESNEL BC V2J3J5 CANADA 
TSUKISHIHA LLOYD M © PROGRAMHER/ANALYST WEST FRASER MILLS P 0 BOX 4006 QUESNEL BC V2J375 CANADA 
KILHON JR LINE SENIOR ENGINEER WESTERN ELECTRIC CO 2509 BROENING HWY BALTIMORE MD 21224 USA 
NEUMYER RICHARD D SENIOR ENGINEER WESTERN ELECTRIC CO 2500 BROENING HUY BALTIMORE HD 21224 USA 
ECKARD DAVID L SYSTEM ANALYST WESTINGHOUSE ELEC C PQ BOX 9475 PHILADELPHIA PA 49413 USA 
BROOKE ROGER G MGR SUPPORT SERVICE WESTINGHOUSE ELEC CORP P O BOX 8839 PITTSBURGH PA {5224 USA 
NC GEOY JOHN G HER DATA SERVICES WESTINGHOUSE ELEC CORP P 0 BOX 8839 PITTSBURGH PA 45224 USA 
ANDERSON EDWARD W == SR SYSTEMS SPECIALIST § WEYERHAEUSER CO AFB 4 TACOMA WA 98402 USA 
GOJENOLA BEN SR SOFTWARE DESIGNER WEYERHAEUSER CO 10TH & A STREETS RMB-2 TACOMA WA 98404 USA 
ROBERTSON DENNIS L MGR DIST PROC TECH SP © WEYERHAEUSER CO 10TH & A STREETS RMB-{ TACOHA WA 98401 USA 
HELLANS CAROLE D P PROG ANALYST WHARTON CO JR COLLEGE 911 BOLING HIGHWAY WHARTON 1X 77488 USA 
PERKINS ALAN L SYSTEMS HMGR/PGHR WHITE HOUSE COMM THE WHITE HOUSE WASHINGTON DC 22076 USA 
HOLT WAYNE E DIRECTOR OR DP WHITMAN COLLEGE 345 BOYER AVE WALLA WALLA WA 99362 USA 
HAINES OLIN R DATA PROCESSING MANAGER WICHITA EAGLE & BEACON 825 E DOUGLAS WICHITA KS 67202 USA 
JENSEN HAROLD E SYSTEMS ANALYST WILLAMETTER VALLEY CO 660 HC KINLEY EUGENE OR 97402 USA 
TURRER WILLIAN A PROF ASSOCIATE WILLIA M MERCER INC 409 GRISWOLD DETROIT MI 48226 USA 
STRANDHAGEN DEBRA A SYSTEM CONTROL WILLIAM M MERCER INC 409 GRISWOLD DETROIT HI 48226 USA 
ENGLANDER WILLIAM R  P CONSULTANT WILLIAM R ENGLANDER 1966 TITUS STREET SAN DIEGO CA 92110 USA 
FARRELL JIM G DIRECTOR MARKET RESEARCH WH C BROWN PUB CO 2460 KERPER BLVD DUBUQUE TA $2001 USA 
HAMPTON JEAN K PROGRAMMER WH C BROWN PUB COMPANY 2460 KERPER BLVD DUBUQUE TA S2004 USA 
HEIN NORM MANAGER INFO SERVICES WMC BROWN PUB COMPANY © 2460 KERPER BLVD DUBUQUE TA 52001 USA 
POWERS DENNIS D DIRECTOR INFO SERVICE WHC BROWN PUB COMPANY 2460 KERPER BLVD DUBUQUE TA S200i USA 
SCHICK JOHN A PROGRAMMER WHC BROWN PUB COMPANY © 2460 KERPER BLVD DUBUQUE TA S2001 USA 
SNESRUD MARGARET J © PROJECT DIRECTOR WHC BROWN PUB COMPANY © 2460 KERPER BLVD DUBUQUE TA S200i USA 
SNESRUD WALLY if PROGRAMMER WHC BROWN PUB COMPANY = 2460 KERPER BLVD DUBUQUE TA S200i USA 
WOOD WALTER A VICE PRESIDENT WOOD BROWN & ASSOCIATES 1473 CARLING SUITE 40S OTTAWA ON K2AiC4 CANADA 
BROWN EDWIN J PRESIDENT WOOD, BROWN & ASSOCIATES © 1673 CARLING AVE OTTAWA ON K2AiC4 CANADA 


COMPANY-14 


ATTENDEE BY COMPANY 


NAHE TITLE CORPANY ADDRESS CITY STATE ZIP COUNTRY 
BADGER PATRICK S DIRECTOR ACADEMIC COM XAVIER UNIVERSITY NEW ORLEANS LA 70425 USA 
GREGORY KENT A ACTUARY /PROGRAHNER ZISCHKE ORGANIZATION { POST STREET SAN FRANCISCO CA 94104 USA 


COMPANY-15 


CONFERENCE VENDOR LISTING INDEXED BY COMPANY 


NAME TITLE COMPANY ADDRESS CITY STATE ZIP COUNTRY 
BEVERLY SHEPHERD OPERATIONS SUPERVISOR ACADEMIC COMP CENTER UNIVERSITY OF WISCONSIN RIVER FALLS WI 54022 USA 
ROSS SCROGES ALTERSABILITY 534 ROSAL AVE OAKLAND CA 74640 USA 
JOHN 4 GRILLOS VICE PRESIDENT AMERICAN MANAGEMENT SYSTE S64 PILGRIM DRIVE, SUITE D SAN MATEO CA 94404 USA 
JR DAUGHERTY DIR DATA PROCESSING AMERICAN SUBSCRIPTION TV 8383 WILSHIRE BLYD-SUITE900 BEVERLY HILLS CA 90244 USA 
BUD BOOTH PRESIDENT AUTOMATED ANALYSIS 3105 DONA SOFIA DR STUDIO CITY CA 94684 USA 
HARK ROBBINS SALES REPRESENTATIVE BARNHILL THREE INC 1780 5 QUEBEC - UNIT 4 DENVER CO 80231 USA 
DONNA CALDWELL BUSINESS MANAGER BOEING COMPUTER SERVICES 874 SO NASH ST - SUITE 1404 EL SEGUNDO CA 90245 USA 
DR DAVIDSON MARKETING PROMOTION MGR CALCCHP 1270 N KRAEMER ANAHETH CA 92806 USA 
ANDREW JAMES MARKETING MANAGER CARROLL MFG CO {2i2 HAGAN CHAMPAIGN IL 61820 USA 
PETER MELVIN MARKETING DIRECTOR CMC ASSOCIATES INC 755 BOYLSTON ST BOSTON HA 02021 USA 
CHARLES W JACKSON = PRESIDENT COLLIER-JACKSON & ASSOC i805 N WESTSHORE BLVD - SUI TAMPA FL 33607 USA 
ROGER GOLDMAN SYSTEMS ANALYST COMARCO INC ee7 W HUENEME RD OXNARD CA 93030 USA 
ED ST AKOUR NATIONAL SALES MANAGER COMPUTER PERIPHERAL SVS 3487 “F" AIRWAY AVE COSTA MESA = CA -92626 USA 
CHARLES YARBROUGH = VICE PRESIDENT COMPUTERS FOR MARKETING 245 MARKET ST - SUITE 1212 SAN FRANCISCO CA 94405 USA 
DAVID C DUMMER PRESIDENT DC DUMMER & ASSOCIATES 40 LAKE LUCERNE CLOSE SE CALGARY AL T2J3HB CANADA 
KEN LESSEY ASSOCIATE DATACON OF ST HELENS SQ WEST STREET oT HELENS OR 9705i USA 
DOUGLAS L MURRAY SALES ENGINEER GANDALF DATA INC 882i RUTGERS ST WESTMINSTER (0 80030 USA 
RELLA HINES EXECUTIVE DIRECTOR HP GENERAL SYSTEMS USERS P.O. BOX 48343, BWI BR. BALTIHORE MD 21240 USA 
RICK GRIFFIN PRESIDENT ICS SERVICES INC 213i W EULESS BLVD EULESS TX USA 
JOSEPH RAUH TECHNICAL SHOWMAN INTEGRATED SOFTWARE SYSTE 4186 SORRENTO VALLEY BLVD SAN DIEGO CA 92i2i USA 
CHRISTOPHER DAVY HANAGER GOVERNMENT SERV KEYDATA CORPORATION £400 WILSON BLVD-SUITE 400 ARLINGTON VA 22209 USA 
MARTIN GORFINKEL PARTNER LOS ALTOS RESEARCH CENTER 339 SOUTH SAN ANTONIO ROAD LOS ALTOS CA 94022 USA 
GARY D ANDERSON ASSOC PROF OF BIOSTAT MC MASTER UNIVERSITY 1200 MAIN ST WEST HANILTON ON LBS4J9 CANADA 
HANAGER MINI PERIPHERAL PRGRHS MEMOREX CORP, BUS SYS DIV 3045 DAIMLER STREET SANTA ANA CA 92705 USA 
DAVID W PIDWELL VICE PRESIDENT, SALES § MINICOMPUTER ACCESSORIES 130 S WOLFE RD PO BOX 9004 SUNNYVALE CA 94086 USA 
SUSAN FEINBERG VICE PRESIDENT NICHOLS AND COMPANY 1900 AVENUE OF THE STARS ST LOS ANGELES CA 90067 USA 
CHARLES J VILLA JR = PRESIDENT PANTECHNIC SB05 OCEAN VIEW DR OAKLAND CA 94618 USA 
LARRY GRESS PRESIDENT PROGRESSIVE COMMUNICATION 340 / ALAMO {28 S$ TEJON COLORADO SPRI CO USA 
WILLIAM E MOORE MARKETING MANAGER R SHRIVER ASSOCIATES 1530 CHESTNUT ST-SUITE 714 PHILADELHIA PA 19462 USA 
ROBERT 4M GREEN PRESIDENT ROBELLE CONSULTING LTD #150-5421 {0TH AVE DELTA BC V4H3T9 CANADA 
DONALD S KLETT DIR UNIV LAB SANGAMON STATE UNIVERSITY SHEPHERD ROAD SPRINGFIELD IL 62708 USA 
STEVE JAMISON HANAGER/MARKETING SUPP SATELLITE COMPUTING INC 4530 PROFESSIONAL CIRCLE © VA BEACH VA 23455 USA 
LAWRENCE MEYERS JR SYSTEMS RESEARCH INC 244 E SAGINAW ST E LANSING HI 48823 USA 
PHILLIP G BEGICH APPLICATIONS ENGINEER = TELEFILE COMPUTER PRODUCTS {7434 DAIMLER ST IRVINE CA 92714 USA 
MICHAEL B MARFES ACCOUNT REPRESENTATIVE TEXAS INSTRUMENTS 9725 E HAMPDEN AVE DENVER CO 80231 USA 
JOHN A DAMM JR PRINCIPAL THE PALO ALTO GROUP 790 LUCERNE DR SUNNYVALE CA 94086 USA 
JACK KENNEY DISTRICT MANAGER UARCO {805 SOUTH BELLAIRE ST - DENVER CO 80222 USA 
JAYNIA LYNN GRACE = MARKETING MANAGER UNITED COMPUTING SYSTEMS 2525 WASHINGTON KARSAS CITY HO 64108 USA 
R R MURRAY MANAGER, MARKETING COMM VERSATEC INC 2805 BOWERS AVE SANTA CLARA CA 95051 USA 
ROBERT A VASCONCELLOS OWNER WHERE ENDS HEET 5926 WHITNEY ST OAKLAND CA 74609 USA 


VENDOR {1 
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